Resiliencia de BrowserContext de larga duración

Un script breve puede crear un contexto y terminar antes de que aparezca una interrupción de red o un problema gradual. Un BrowserContext que permanece activo durante horas debe gestionar fallos del navegador, cortes temporales, leases vencidos, mantenimiento y reinicios. La meta no es mantenerlo vivo para siempre, sino hacer que la continuación, la recuperación y el cierre sean previsibles.

El contexto es un lease con propietario

Cada contexto necesita un propietario y un registro de ciclo de vida. El registro puede incluir la referencia del trabajo, el perfil aprobado, las políticas de almacenamiento y ruta, la versión del navegador y las marcas de creación, checkpoint y cierre. No debe guardar credenciales ni contenido de páginas.

Usa estados como planned, starting, active, degraded, draining y closed. Las transiciones deben ser idempotentes porque una notificación puede repetirse. El lease tiene vencimiento y regla de renovación. Cuando la renovación se detiene, el planificador pausa el trabajo nuevo y comienza la reconciliación.

Perfil, almacenamiento, ruta y configuración regional permanecen unidos al lease. La recuperación puede recrear la misma asignación aprobada, pero no debe sustituirla silenciosamente. Si hace falta otra identidad, cierra el lease anterior y crea una nueva sesión.

Separar intención persistente y estado volátil

El proceso, las páginas abiertas y las conexiones son volátiles. La intención persistente describe el objetivo, el último checkpoint confirmado, el presupuesto de reintentos y la limpieza. Un checkpoint debe representar una confirmación de la aplicación, no solo una navegación correcta.

Escribe el checkpoint junto con la versión del lease. Un conflicto de versión exige reconciliación, no una segunda ejecución. Cookies, almacenamiento local, descargas y borradores tienen reglas distintas. Persiste solo lo que la política autoriza y que puede restaurarse de forma comprensible.

Hacer reproducibles el inicio y la restauración

Antes de abrir la primera página, valida la versión, la propiedad del almacenamiento y la ruta. La restauración sigue una secuencia fija: adjuntar la asignación, crear el contexto, aplicar ruta y configuración regional, ejecutar una comprobación de salud y reanudar el trabajo. Registra una generación para rechazar mensajes tardíos del worker anterior.

El inicio debe tener un límite. Si el contexto no se vuelve saludable, pasa a revisión o a un reintento controlado. Esperar sin límite oculta la saturación y conserva un espacio del planificador.

Recuperarse de un fallo del navegador

Marca el lease como degradado y detén el trabajo nuevo. Conserva evidencia no sensible: versión, generación, último checkpoint y estado del host. Si hay otros contextos en el mismo grupo, el propietario del grupo decide si el impacto es local o general.

Reutiliza almacenamiento solo cuando su integridad sea conocida. De lo contrario, aíslalo y usa el estado permitido. Las acciones de recuperación deben ser idempotentes. Si una operación ya pudo completarse, pide confirmación a la aplicación antes de repetirla. Ante la duda, detente en el checkpoint.

Dar un presupuesto a los reintentos de red

Una solicitud, una conexión larga y el canal de control son fallos diferentes. Registra la categoría, limita los intentos y añade espera. Las lecturas pueden repetirse, pero una escritura o un envío requiere confirmación de la aplicación.

Los reintentos deben usar la ruta aprobada. Si cambiar de ruta cambia la identidad regional, cierra el lease y crea una sesión nueva. Cuando se agota el presupuesto, marca un fallo recuperable y libera capacidad solo después de limpiar el contexto.

Reciclar en una frontera explícita

El reciclaje puede producirse por mantenimiento, una actualización o un estado imposible de reparar. Detén la admisión, termina o cancela la acción, escribe el checkpoint final, cierra páginas y contexto, y confirma la limpieza antes de liberar el lease. Nunca reemplaces el navegador bajo un contexto activo.

Una sesión autorizada no debe reciclarse solo para cambiar de identidad. Si la política exige una nueva asignación, registra la frontera y no reutilices el almacenamiento anterior.

Validar la coherencia

Observa las relaciones: un lease por propietario, un almacenamiento por contexto, checkpoints ordenados y un cierre para cada apertura. Los paneles pueden mostrar edad de cola, restauraciones, fallos, reintentos y tiempos de cierre sin guardar secretos ni contenido privado.

Para una verificación reproducible, ejecuta un trabajo aprobado y provoca una sola interrupción controlada. Compara asignación, configuración regional, ruta, propiedad del almacenamiento, checkpoints y resultado final. Comprueba además que el contexto antiguo está cerrado y que el nuevo tiene un solo propietario.

Consulta el Proof Center de BotBrowser para conocer el alcance público de validación de coherencia. La guía de memoria de BrowserContext y escalado de contextos cubren capacidad y ciclo de vida.

Lista operativa

• El lease tiene propietario, vencimiento y transiciones repetibles.
• Perfil, almacenamiento, ruta y versión se asignan antes del trabajo.
• Los checkpoints no contienen secretos.
• Los fallos y reintentos tienen límites claros.
• El reciclaje confirma la limpieza antes de devolver capacidad.
• Las pruebas comparan registros estructurados y verifican el cierre.

Si la propiedad o la limpieza es incierta, pausa la admisión y reconcilia primero. El navegador puede reiniciarse y el worker puede cambiar, pero el servicio debe explicar qué asignación estaba activa, qué trabajo se confirmó y por qué se creó un contexto nuevo.