Dans un parking souterrain (hors ligne), une fonctionnalité désactivée est silencieusement réactivée après reconnexion, lorsque la première synchronisation l’écrase avec une ancienne valeur on du serveur. Voici l’analyse du moment où, dès lors que le serveur fait foi et qu’il existe plusieurs appareils, un simple toggle de réglage devient un problème de synchronisation d’état distribué. Le cas étudié concerne iOS, mais il parle de tous les clients qui gèrent des feature flags ou des paramètres de notification.
Règle de priorité de synchronisation — intention utilisateur non encore propagée > valeur serveur > cache local
Défauts secondaires créés par le flag d’intention (zombie flags · ordre renvoi-lecture)
Blocage complet des 5 chemins de résurrection d’un état désactivé (réponse 200 tardive · file de retry · restauration au démarrage · push · hook de debug)
Revalidation par relecture du contrat serveur de production en 7 cas (champ de reçu d’initialisation d’état de la transaction off)
Si le réglage est stocké côté serveur, 3 questions auxquelles il faut répondre quelle que soit la plateforme — stale / résurrection / convergence
Aucun commentaire pour le moment.