Recuperar una sesión del navegador tras una interrupción de red
Use reintentos acotados, puntos de control y límites de privacidad para recuperar trabajo del navegador sin duplicar efectos.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Una interrupción de red no demuestra si una acción terminó. La conexión puede fallar antes de la solicitud, después de que el servidor la aceptó o mientras el worker esperaba la respuesta. Recupere con seguridad conservando la asignación de sesión, registrando un punto de control y repitiendo solo operaciones cuya finalización pueda confirmarse.
Resumen
- Clasifique el canal: solicitud de página, websocket, ruta proxy o canal de control.
- Mantenga estables profile, almacenamiento, idioma y ruta durante la generación de recuperación.
- Reintente lecturas y operaciones idempotentes con un límite; confirme las escrituras antes de repetirlas.
- Separe la limpieza visible del navegador de la revocación del servidor y del borrado del host.
- BotBrowser repite un punto de control autorizado, pero no puede inferir si un efecto externo fue aceptado.
Contenido
- Fijar el contrato de sesión
- Usar puntos de control y una tabla
- Recuperar con un presupuesto acotado
- Proteger la privacidad y verificar
- Capacidad y límite de BotBrowser
- Conclusión
- Preguntas frecuentes
Fijar el contrato de sesión
Antes de abrir la página registre referencia del trabajo, profile aprobado, propietario del almacenamiento, versión del navegador, política de ruta y generación de lease. No incluya contraseñas, cuerpos de página ni URL innecesarias. Tras una reparación, rechace mensajes de generaciones antiguas.
Separe la intención durable del estado volátil. La intención contiene acción, último punto aceptado, presupuesto de reintento y limpieza. Páginas abiertas, memoria, websockets y solicitudes en curso son volátiles.
Usar puntos de control y una tabla
Un punto de control es un límite de aceptación definido por la aplicación: respuesta validada, documento guardado en destino autorizado o acuse documentado. Una navegación correcta no prueba un efecto lateral.
| Límite observado | Primera acción | Regla | Resultado esperado |
|---|---|---|---|
| Lectura fallida antes de responder | Reconectar y leer | Reintento acotado con jitter | Lectura validada o fallo clasificado |
| Escritura sin acuse | Consultar estado | Repetir solo con clave idempotente | Un resultado registrado |
| Canal de control perdido | Pausar admisión y reconciliar | No repetir acciones a ciegas | Un propietario continúa o se aísla |
| Ruta no disponible | Pausar asignación | No cambiar a ruta ajena | Fallo recuperable visible |
La aplicación debe ofrecer consulta de estado o idempotencia. Si no la ofrece, deténgase en el punto de control y solicite conciliación.
Recuperar con un presupuesto acotado
Clasifique solicitud, websocket, proxy o control. Use máximo de intentos y de antigüedad con demoras variables. Mantenga la ruta declarada; cambiarla puede cambiar la identidad de red y exige un nuevo lease según la política.
Al agotar el presupuesto marque fallo recuperable, conserve el punto aceptado, drene el context y aísle el almacenamiento incierto. Registre generación, versión, intentos y categoría sin tokens ni URL privadas.
Proteger la privacidad y verificar
Cookies, almacenamiento, IndexedDB, caché, descargas y sesiones del servidor tienen ciclos distintos. MDN Clear-Site-Data describe limpieza por origin, no borrado remoto. Los principios de privacidad de W3C respaldan minimización y limitación de propósito.
Compare asignación, ruta, orden de puntos, acuse y limpieza en evidencia estructurada. Use un context autorizado nuevo para comprobar el estado esperado. Marque como pendiente toda revocación remota asíncrona.
Capacidad y límite de BotBrowser
BotBrowser puede repetir un punto de control autorizado en profile, versión, ruta y context declarados y comparar resultados visibles tras una interrupción controlada. No puede determinar si el servidor aceptó una escritura sin acuse, revocar sesiones, inspeccionar todos los artefactos del host ni garantizar continuidad. El propietario de la aplicación decide idempotencia, autorización, retención y aceptación.
Lecturas relacionadas: Resiliencia de contextos de larga duración y Consistencia de la capa de red.
Conclusión
Recupere la intención, no la conexión perdida: congele la propiedad, verifique el último límite, concilie escrituras inciertas y limite los reintentos. La acción siguiente es ejecutar un fixture autorizado con una interrupción inyectada y comprobar resultado y limpieza.
Un registro útil conserva un identificador estable, la versión del punto de control, el intento, la clase de ruta y un resultado breve como confirmado, desconocido o aislado. No debe copiar el historial de navegación: excluya secretos, cuerpos de solicitudes, URL completas y capturas.
Cada punto debe nombrar la autoridad que responde la siguiente pregunta: acuse de la aplicación, consulta por clave de idempotencia, estado de transacción o decisión de un responsable. Sin esa autoridad, conserve la incertidumbre y detenga el lease en lugar de inventar otra escritura.
La evidencia del navegador y la del servicio son distintas. La primera muestra una solicitud enviada, una respuesta leída o un context cerrado; la segunda muestra una transacción confirmada, deduplicada o revocada. Una aserción verde del navegador no prueba un commit remoto.
Para una descarga interrumpida, compare tamaño o digest cuando exista, aísle archivos ambiguos y haga visible la limpieza. Para un websocket desconectado, compare la revisión y repita solo operaciones declaradas seguras por el servidor.
Un cambio de ruta merece su propio punto: puede cambiar ubicación, política o autorización. Cierre el lease anterior, registre la razón y compruebe la política antes de continuar.
La aceptación final puede ser una tabla breve: propietario, punto, acuse del servidor, limpieza del navegador y conservación. Marque cada fila como observada, pendiente o no aplicable. Recoja solo señales necesarias y no combine fingerprint, proxy y sesión en una identidad permanente.
Preguntas frecuentes
¿Todo timeout se reintenta?
No. Reintente lecturas o acciones con contrato idempotente; consulte estado antes de repetir una escritura desconocida.
¿Un context nuevo conserva la sesión?
Solo si la política permite el mismo profile y almacenamiento íntegro. No conserva memoria volátil por sí solo.
¿Limpiar datos revoca la sesión del servidor?
No. Son fronteras distintas y requieren evidencias distintas.
¿Qué verifica BotBrowser?
Reproduce el punto autorizado y compara resultados visibles; no certifica efectos remotos ni borrado del host.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.