Résilience des BrowserContext de longue durée

Un script court peut créer un contexte, effectuer une action puis se terminer avant qu'une interruption réseau ou un problème progressif ne soit visible. Un BrowserContext qui reste actif pendant des heures doit gérer les crashs, les interruptions temporaires, les baux expirés, la maintenance et les redémarrages. L'objectif n'est pas de conserver chaque contexte indéfiniment, mais de rendre la reprise et la fermeture prévisibles.

Un contexte est un bail avec un propriétaire

Chaque contexte doit avoir un propriétaire et un enregistrement de cycle de vie. Cet enregistrement peut contenir la référence du travail, le profil autorisé, la politique de stockage et de route, la version du navigateur, ainsi que les temps de création, de point de contrôle et de fermeture. Il ne doit pas contenir de secrets ou de contenu de page.

Utilisez des états explicites comme planned, starting, active, degraded, draining et closed. Les transitions doivent être idempotentes, car un message de fermeture peut arriver deux fois. Le bail possède une échéance et une règle de renouvellement. Si le renouvellement cesse, le planificateur arrête les nouveaux travaux et lance une réconciliation.

Le profil, le stockage, la route et la locale restent liés au bail actif. Une reprise peut recréer la même affectation autorisée, mais ne doit pas remplacer silencieusement le profil ou la route. Si une nouvelle identité est nécessaire, fermez l'ancien bail et créez une nouvelle session.

Séparer l'intention durable de l'état volatile

Le processus navigateur, les pages ouvertes et les connexions réseau sont volatils. L'intention durable doit décrire l'objectif, le dernier point confirmé, le budget de reprise et la politique de nettoyage. Un point de contrôle doit correspondre à une condition applicative confirmée, pas seulement à une navigation réussie.

Écrivez le point de contrôle avec la version du bail. Une collision de version doit déclencher une réconciliation, et non une seconde exécution. Cookies, stockage local, téléchargements et brouillons ont des règles de conservation différentes. Ne persistez que ce que la politique autorise et peut réellement restaurer.

Rendre le démarrage reproductible

Avant la première page, vérifiez la version approuvée, la propriété du stockage et la route. La reprise suit une séquence stable : rattacher l'affectation, créer le contexte, appliquer la locale et la route, exécuter un contrôle de santé, puis reprendre le travail. Enregistrez la génération de reprise afin que les messages retardés d'un ancien worker soient refusés.

Le démarrage doit avoir une limite. Un contexte qui ne devient pas sain dans le délai prévu passe en revue ou en nouvelle tentative contrôlée. Une attente infinie masque la saturation et garde un emplacement du planificateur occupé.

Récupérer après un crash

Après un crash, marquez le bail comme dégradé et arrêtez les nouveaux travaux. Conservez des éléments non sensibles : version, génération, dernier point de contrôle et état de l'hôte. Si plusieurs contextes partagent un groupe, le propriétaire du groupe décide si l'impact est local ou général.

Réutilisez le stockage seulement si son intégrité est connue. Sinon, isolez-le et démarrez avec l'état autorisé. Les reprises doivent être idempotentes : une action déjà effectuée doit être confirmée par l'application avant une nouvelle tentative. En cas de doute, arrêtez-vous au point de contrôle.

Donner un budget aux reprises réseau

Une requête, une connexion longue et le canal de contrôle représentent des pannes différentes. Attribuez des catégories, un nombre limité de tentatives et un délai. Les lectures peuvent parfois être rejouées, mais une soumission ou une modification de fichier nécessite une confirmation applicative.

Restez dans la route approuvée. Un changement qui modifie l'identité régionale doit fermer le bail et créer une nouvelle session. Lorsque le budget est épuisé, marquez l'échec récupérable et ne rendez la capacité qu'après le nettoyage.

Recycler au bon moment

Le recyclage peut suivre une limite de maintenance, un changement de version ou un état impossible à réparer. Arrêtez l'admission, terminez ou annulez l'action, écrivez le dernier point de contrôle, fermez les pages puis le contexte, et confirmez le nettoyage avant de libérer le bail. Ne remplacez jamais le navigateur sous un contexte actif.

Une session autorisée continue ne doit pas être recyclée uniquement pour changer d'identité. Lorsque la politique impose une nouvelle affectation, documentez la frontière et ne réutilisez pas l'ancien stockage.

Vérifier la cohérence

Surveillez les relations : un bail par propriétaire, un stockage par contexte, des points de contrôle dans l'ordre et une fermeture pour chaque ouverture. Les tableaux peuvent montrer l'âge de la file, les reprises, les crashs, les délais de fermeture et les ressources résiduelles sans conserver les secrets ou le contenu des pages.

Pour une validation reproductible, exécutez un travail autorisé, notez l'affectation et introduisez une seule interruption contrôlée. Comparez ensuite l'affectation, la locale, la route, la propriété du stockage, les points de contrôle et le résultat final. Confirmez aussi que l'ancien contexte est fermé et que le nouveau possède un seul propriétaire.

Consultez le BotBrowser Proof Center pour le périmètre public de validation de la cohérence navigateur. Le guide de mémoire des contextes et l'article sur la mise à l'échelle des contextes complètent cette méthode.

Liste de contrôle

• Le bail possède un propriétaire, une expiration et des transitions répétables.
• Profil, stockage, route, locale et version sont choisis avant le travail.
• Les points de contrôle n'enregistrent pas de secrets.
• Crashs et reprises réseau ont un budget limité.
• Le recyclage confirme le nettoyage avant de rendre la capacité.
• Les tests d'interruption comparent des enregistrements structurés.

Lorsque la propriété ou le nettoyage est incertain, suspendez l'admission et réconciliez d'abord. Un navigateur peut redémarrer et un worker peut être remplacé, mais le service doit toujours pouvoir expliquer quelle affectation était active, ce qui a été confirmé et pourquoi un nouveau contexte a été créé.