Mises à jour des service workers et cohérence des clients

BotBrowser peut créer des contextes de navigateur contrôlés et exposer l’état de l’enregistrement et des clients observé par un test. Il ne modifie pas l’algorithme de mise à jour du service worker, ne rend pas un worker waiting actif de lui-même et ne décide pas quand une page peut être rechargée sans risque. Le contrat de coordination appartient à l’application ; BotBrowser fournit des contextes et des points d’observation reproductibles.

TL;DR

Une mise à jour est une séquence, pas un simple téléchargement. Découvrez le candidat avec ServiceWorkerRegistration.update(), observez les états installing, waiting et active, identifiez les clients contrôlés et ne coordonnez le rechargement qu’une fois la nouvelle version prête et compatible avec eux. Conservez les identités des scripts ancien et nouveau, les états des clients, le choix de l’utilisateur et le résultat après rechargement. Si la nouvelle version échoue, arrêtez sa promotion, restaurez le dernier script connu comme correct et vérifiez l’ancienne version avec des preuves fraîches. Ce flux ne promet pas que tous les navigateurs se mettront à jour au même moment.

Contents

• Modéliser les états de mise à jour
• Garder les clients contrôlés cohérents
• Coordonner un rechargement sûr
• Rendre les preuves de rollback utiles
• Valider une livraison
• Conclusion pratique

Modéliser les états de mise à jour

Pendant que le navigateur évalue un script candidat, il conserve le service worker active existant. Un enregistrement peut donc exposer trois références distinctes : installing pendant l’installation du candidat, waiting une fois l’installation terminée mais avant la prise en charge, et active pour la version qui sert les clients contrôlés. Ce sont des états à observer, pas des synonymes de « le serveur possède le nouveau fichier ».

registration.update() demande au navigateur de vérifier si l’URL du script de l’enregistrement possède une version plus récente. La référence MDN décrit la promesse renvoyée : elle se résout avec l’enregistrement quand la vérification est terminée et se rejette quand la mise à jour ne peut pas aboutir. Une promesse résolue ne prouve pas qu’une nouvelle version a été trouvée ou activée. Lisez ensuite registration.installing, registration.waiting et registration.active, et écoutez updatefound pour un candidat apparu de manière asynchrone.

L’événement statechange du worker en cours d’installation est une limite utile pour un message visible. installing signifie que le candidat n’est pas prêt à coordonner un rechargement. Lorsqu’un worker active ou des clients contrôlés existent déjà, installed peut rester en waiting ; lors d’une première installation sans worker active, il passe à activating puis activated. installed ne signifie pas à lui seul active. activating est une transition, pas une identité de version stable. activated prouve que l’enregistrement possède un nouveau worker active, mais une page peut encore devoir être rechargée avant d’être contrôlée.

Une petite table donne un seul sens à chaque transition :

État observé	Interprétation sûre	Action suivante
installing	Un candidat est en préparation	Garder la page et attendre statechange
waiting	Le candidat est prêt, mais des clients existants peuvent encore utiliser l’ancienne version active	Afficher un choix de rechargement avec une note de compatibilité
active sans changement de controller	L’enregistrement est actif, mais cette page peut rester sous l’ancienne version	Attendre controllerchange ou une navigation volontaire
controllerchange	La version qui contrôle la page a changé	Réconcilier l’état, puis recharger une seule fois si nécessaire

Ne déduisez pas l’état d’un horodatage, d’une réponse 200 ou d’une nouvelle URL de script. Le navigateur peut vérifier à un autre moment et un client peut rester sous l’ancien controller pendant qu’un autre avance.

Garder les clients contrôlés cohérents

navigator.serviceWorker.controller indique quel worker active contrôle la page, ou vaut null lorsqu’elle ne l’est pas. Capturez l’URL du script du controller ou un identifiant de livraison exposé par l’application avec l’état de l’enregistrement. Vous distinguez ainsi « le candidat est installé » de « cette page fonctionne sous le candidat ».

Une application à plusieurs onglets doit prendre une décision unique sur le moment où elle avance. Un onglet peut observer waiting et diffuser aux autres clients contrôlés un signal neutre « mise à jour prête ». Chaque onglet doit afficher le même identifiant et permettre de différer le rechargement. Un onglet qui contient un formulaire non enregistré ne doit pas être rechargé parce qu’un autre est prêt.

Le message de mise à jour doit porter des faits, pas des ordres qui masquent une transition : livraison candidate, livraison du controller actuel, état de préparation et identifiant de requête. À sa réception, chaque onglet relit son enregistrement et son controller. Il n’agit donc pas sur un message périmé après l’arrivée d’une seconde mise à jour.

La compatibilité décide. Si le candidat change les formats de réponse, les hypothèses de navigation ou le protocole de page, il ne doit pas prendre le relais d’une page ouverte sans chemin de migration. Marquez « recharger ensemble » les versions qui ne peuvent pas coexister. Une version rétrocompatible peut afficher un message moins intrusif, mais elle doit toujours vérifier explicitement le controller.

BotBrowser peut ouvrir des contextes contrôlés séparés et capturer l’état de chaque page. Il ne peut pas faire partager un controller à deux contextes ni décider si le protocole d’une application est compatible. Le test doit déclarer quels clients avancent ensemble et lesquels peuvent rester sur l’ancienne version.

Coordonner un rechargement sûr

Annoncez d’abord que la mise à jour est prête dans l’interface, sans forcer la navigation. Indiquez la livraison candidate et une brève raison. Gardez le choix jusqu’à ce que la page soit sûre : aucun formulaire, envoi, paiement ou travail non enregistré ne doit être perdu. Offrez un chemin de navigation ultérieur à la personne qui choisit « plus tard ».

Confirmez ensuite l’état juste avant le rechargement. Lisez registration.waiting, le worker active et navigator.serviceWorker.controller, puis comparez leurs identifiants à ceux du message qui a ouvert l’avis. S’ils diffèrent, fermez l’avis et vérifiez à nouveau au lieu de recharger avec une information périmée.

Coordonnez enfin la transition. La page peut écouter controllerchange, cesser d’accepter du nouveau travail, conserver seulement l’état autorisé par le produit et recharger une fois. Protégez le rechargement par un indicateur par page pour éviter une boucle lors d’une rafale d’événements. Une page qui reçoit controllerchange après avoir commencé sa navigation la termine et enregistre le controller obtenu.

Cette séquence minimale observe l’état ; elle ne force pas l’activation :

let reloadIssued = false;
let reloadApproved = false;

function approveReload() {
  reloadApproved = true;
}

navigator.serviceWorker.addEventListener('controllerchange', () => {
  if (reloadIssued || !reloadApproved) return;
  if (document.querySelector('[data-unsaved-work="true"]')) return;
  reloadIssued = true;
  window.location.reload();
});

async function checkForUpdate(registration) {
  await registration.update();
  return {
    installing: registration.installing?.state ?? null,
    waiting: Boolean(registration.waiting),
    active: registration.active?.scriptURL ?? null,
    controller: navigator.serviceWorker.controller?.scriptURL ?? null,
  };
}

La stratégie d’activation doit correspondre au protocole de page et au travail en cours. Pour un formulaire critique, laissez la personne terminer puis vérifiez le controller après la navigation suivante ; pour une interface en lecture seule, un choix immédiat convient lorsque la compatibilité est établie.

Rendre les preuves de rollback utiles

Le rollback est une décision de livraison fondée sur des observations. Conservez l’identité du script connu comme correct, celle du candidat, la version du navigateur, l’identifiant du contexte et le parcours qui a échoué. Ajoutez les heures de découverte, d’activation, de changement de controller et de fin de rechargement. Les preuves nécessitent les transitions, pas les données de compte ou les corps de requête.

Point de contrôle	Preuve conservée	Décision
Avant promotion	Identité connue comme correcte et résultat de parcours réussi	La base est restaurable
Découverte du candidat	Résultat de update(), états de l’enregistrement et identité candidate	Le candidat a été réellement observé
Après rechargement	Identité du controller, livraison de page et résultat du parcours	Le client a avancé de façon cohérente ou non
Après rollback	Identité restaurée et nouveau résultat du parcours	Le rollback est effectif, pas seulement configuré

Lorsqu’un parcours échoue, arrêtez la promotion et comparez l’identité du controller à la livraison attendue. Restaurez le script connu comme correct par le chemin normal de livraison, ouvrez un contexte neuf et répétez le même parcours. Un client déjà contrôlé par le candidat peut nécessiter une navigation coordonnée avant de démontrer la version restaurée ; consignez ce fait et ne déclarez pas le rollback trop tôt.

Le simple fait que l’ancien fichier soit accessible n’est pas une preuve de rollback. La preuve est un client contrôlé qui rapporte la version active restaurée et réussit le parcours qui avait échoué. Conservez le candidat et l’enregistrement de l’échec pour le diagnostic, tandis que le chemin utilisateur ne sert que la version acceptée.

Valider une livraison

Dans un contexte reproductible, couvrez toute la séquence :

1. Chargez la base et notez l’enregistrement, le script actif, le controller et le résultat d’un parcours représentatif.
2. Déployez le script candidat et appelez registration.update() depuis une page déjà contrôlée.
3. Notez installing, waiting, active, updatefound et statechange jusqu’à l’état stable du candidat.
4. Ouvrez un second client contrôlé et confirmez s’il garde l’ancien controller ou avance selon la règle de compatibilité.
5. Choisissez le rechargement dans un client, capturez controllerchange et vérifiez que la page ne se recharge qu’une fois au maximum.
6. Répétez le parcours et comparez-le à la base. Une différence suspend la promotion.
7. Exécutez le rollback avec la même matrice de contextes et conservez la preuve de la version restaurée.

BotBrowser rend ces vérifications reproductibles dans plusieurs contextes contrôlés et versions de navigateur. Il ne certifie pas le contrat de compatibilité de l’application, ne choisit pas le moment de rechargement de l’utilisateur et ne garantit pas un calendrier universel de mise à jour. Ces affirmations nécessitent les preuves propres aux pages et à la livraison.

Pour une base de versions plus large, consultez Validation d’une livraison de navigateur. Pour la récupération d’une session interrompue, consultez Récupération de session après une interruption réseau.

N’écrivez pas seulement « mise à jour réussie ». Pour chaque contexte, notez la version du navigateur, l’URL du script, installing, waiting, active, puis le controller avant et après le message. Notez aussi si la personne a choisi « maintenant » ou « plus tard », car un report est un résultat valide. Une simple mention de succès ne distingue pas un candidat installé, un worker actif et une page contrôlée.

Comparez des identités concrètes plutôt que des noms affichés. Une URL de script avec un identifiant de release immuable donne au site et au test une valeur vérifiable. Si l’identité affichée par la page diffère de celle du controller, gardez la page actuelle et relisez l’état au lieu de forcer la navigation. Chaque onglet doit être enregistré séparément, car les états et les controllers peuvent différer.

Limitez les nouvelles vérifications. Appelez update() de nouveau seulement après la résolution de la promesse précédente et inscrivez le nombre de contrôles. Les appels répétés n’accélèrent pas l’activation et une boucle sans limite peut cacher un problème de serveur ou de compatibilité. À la limite, conservez l’état observé et prenez la décision de release.

Le texte de l’interface doit correspondre à l’état observé. Dites qu’une nouvelle version est prête seulement après avoir vu waiting ou une nouvelle identité active; pendant update(), indiquez que la vérification est en cours. En cas de rejet de la promesse, expliquez que la vérification n’a pas abouti et laissez la page utilisable. Désactivez « recharger maintenant » pendant un téléversement ou un paiement, puis relisez les identités avant la navigation.

Le dossier d’acceptation doit être compréhensible par une personne qui n’a pas exécuté le test. Décrivez le parcours, chaque changement de controller et le résultat du rollback, avec l’identité connue comme saine et un nouveau parcours réussi. Évitez les sorties de console brutes et les données sensibles afin de comparer les contextes.

Le support doit aussi noter si la page a émis controllerchange. Une vérification en arrière-plan ne doit mettre à jour que l’indicateur et l’instantané de l’enregistrement, jamais supprimer le travail de la personne. Les vérifications du navigateur lors d’une navigation doivent entrer dans le même modèle d’états.

Employez un vocabulaire stable : « candidat » pour installing ou waiting, « active » pour la référence active de l’enregistrement et « controller » pour la version qui contrôle la page. Si un candidat est rejeté, notez l’état de l’échec et donnez une nouvelle identité au candidat suivant afin de ne pas mélanger les preuves.

L’acceptation doit répondre à ces points : update() est-il terminé et l’identité observée, quels clients avancent selon la règle, les identités ont-elles été confirmées sans travail protégé, y a-t-il eu au plus un rechargement, et l’identité saine avec un nouveau parcours réussi prouve-t-elle le rollback ? Le résultat ne vaut que pour la matrice déclarée et doit être répété si le script ou le protocole change.

Conclusion pratique

Considérez les mises à jour de service worker comme une coordination entre un enregistrement, un candidat, une version active et les clients qu’elle contrôle. Appelez update() pour découvrir les changements, lisez les états réels, rendez la compatibilité explicite et ne rechargez chaque client qu’après confirmation de la transition. Liez la preuve de rollback à un controller réel et à un parcours reproductible. BotBrowser reproduit ces observations ; la politique de mise à jour reste celle de l’application.

Sources

• W3C Service Workers
• MDN : ServiceWorkerRegistration.update()