Maintenance des caches applicatifs

Cette page documente les differents caches manipules par l'application, leurs points d'entree techniques et les scenarios de purge recommandes. Elle ne couvre pas les caches de build locaux comme .svelte-kit, node_modules/.vite ou les artefacts build.

Probleme traite

L'application conserve plusieurs etats locaux pour fonctionner en environnement TV :

• le cache gere par le service worker ;
• les preferences utilisateur et techniques ;
• les donnees applicatives miroitees dans localStorage ;
• certains caches fonctionnels ciblables, comme area.

Ces caches ameliorent le demarrage et limitent les appels CMS, mais ils peuvent aussi masquer une mise a jour de contenu, conserver une configuration obsolete ou empecher un pipeline CMS de repartir sur un etat propre.

Vue d'ensemble

Les points d'entree de maintenance sont centralises dans src/lib/services/appMaintenanceActions.ts. Les operations bas niveau de stockage sont dans src/lib/utilsStorage.ts, et la communication avec le service worker passe par src/lib/swMessenger.ts.

Service worker cache

Le vidage du cache service worker est demande via clearCache() dans src/lib/swMessenger.ts.

await sendMessageToSW({ type: 'CLEAR_CACHE' });

Cette fonction n'efface pas directement les caches depuis le thread applicatif. Elle envoie un message au service worker actif. Le nettoyage effectif depend donc du handler CLEAR_CACHE cote service worker.

Points d'entree

• clearCacheOnly() : demande uniquement le vidage du cache service worker et affiche un toast informatif.
• clearCacheAndRestart() : appelle clearCacheOnly(), puis relance le pipeline CMS avec cmsPipelineService.restart().

Quand l'utiliser

Utiliser le vidage service worker lorsque :

• des assets ou donnees restent servis depuis un cache obsolete ;
• une mise a jour de contenu ne se reflete pas apres un rechargement simple ;
• une commande distante doit forcer un rechargement CMS propre.

Preferences applicatives

Les preferences sont creees via createPreferencesStore() dans src/lib/stores/preferencesManager.ts. Chaque preference est hydratee avec getData(key) et persistee avec setData(key, value).

Le nettoyage global des preferences est expose par clearPreferences() :

await clearData();

Avec l'implementation actuelle, clearData() sans cle effectue un window.localStorage.clear(). Cela remet a zero les preferences stockees localement, mais ne propage pas une suppression globale au stockage plateforme via le bridge.

Point d'attention plateforme

Pour une suppression ciblee, clearData(key) appelle d'abord :

await platformStorage.set(key, '');

puis retire la cle du localStorage. Cette forme est donc plus explicite pour signaler une suppression au host lorsque la cle est connue.

Stockage local applicatif

Le module src/lib/utilsStorage.ts abstrait l'acces au stockage :

• setData(key, value) ecrit via platformStorage, avec fallback localStorage ;
• getData(key) lit via platformStorage, avec fallback ou priorite localStorage ;
• clearData(key?) supprime une cle precise ou tout le stockage local.

Certaines cles restent volontairement locales ou prioritaires localement.

Categorie	Cles
URL/localStorage uniquement	staging, debug, skipwhoami, preview, mockVendor
Lecture locale prioritaire / miroir local	uid, redirector:*, facility:*, advertising:*, sidebarMenu:*

Cette distinction est importante lors du diagnostic : supprimer uniquement le cache service worker ne supprime pas ces valeurs locales.

Declencheurs disponibles

Menu Settings

Dans l'onglet Stockage & données de src/routes/settings, le bouton Vider les caches applicatifs execute le meme flux que la commande SSE clear avec le message all :

await clearPreferences({
	context: 'settings-storage',
	invalidate: true
});
await clearCacheAndRestart({
	recoverySource: 'settings:app-cache-clear',
	context: 'settings-storage'
});

Depuis l'interface, cette action nettoie donc les preferences locales, demande au service worker de vider son cache, puis relance le pipeline CMS.

Commandes SSE

Dans src/lib/components/sse/SseHandler.svelte, l'evenement clear route le message :

Message SSE	Action
preferences	clearPreferences({ invalidate: true })
cache	clearCacheAndRestart({ recoverySource: 'sse:cache-clear' })
all	Les deux actions ci-dessus

La commande cache est plus forte que le bouton settings, car elle relance aussi le pipeline CMS apres la demande de vidage du service worker.

Combo de touches UUUDDD

Le code telecommande up up up down down down declenche l'evenement global clearAppCachesAndReload. Le handler applicatif execute le meme nettoyage que clear=all, puis appelle window.location.reload() pour conserver le comportement historique du combo.

Cache area

Dans src/lib/components/layout/BackgroundServices.svelte, un refresh SSE dataRoom declenche clearAreaCache().

Cette fonction :

1. supprime la cle area ;
2. met a jour areaUpdated avec un timestamp ;
3. appelle invalidateAll() pour forcer la revalidation SvelteKit.

Ce nettoyage est cible et doit etre prefere quand seul le contexte de chambre ou de zone a change.

Scenarios recommandes

Contenu CMS bloque ou obsolete

Utiliser clearCacheAndRestart().

Cette action combine le vidage du cache service worker et le redemarrage du pipeline CMS. C'est le choix adapte pour une commande distante de maintenance ou pour debloquer un ecran qui conserve des donnees anciennes.

Preference ou configuration incorrecte

Utiliser clearPreferences().

Cette action remet a zero le stockage local applicatif. Elle est adaptee aux cas ou des valeurs comme debug, preview, uid ou des caches facility:* perturbent le comportement.

Changement de chambre, zone ou affectation

Utiliser clearAreaCache().

Cette action limite le nettoyage a la cle area et evite de supprimer toutes les preferences.

Cache service worker uniquement

Utiliser clearCacheOnly().

Cette action est suffisante si le stockage applicatif est correct et que seul le cache gere par le service worker est suspect.

Verification

Apres un nettoyage, verifier :

• la presence du toast applicatif attendu ;
• les logs du tag services/appMaintenanceActions ;
• la disparition des cles concernees dans localStorage ;
• le redemarrage du pipeline CMS lorsque clearCacheAndRestart() est utilise ;
• la bonne reception du message CLEAR_CACHE par le service worker.

Limites connues

• clearData() sans cle vide le localStorage, mais ne signale pas une suppression globale au stockage host.
• clearCache() depend d'un service worker actif. Si aucun service worker n'est disponible, l'action est loguee en erreur et le cache ne peut pas etre purge par ce canal.
• La commande CLEAR_CACHE doit etre implementee cote service worker pour produire un effet reel sur les caches navigateur.

References

• src/lib/services/appMaintenanceActions.ts
• src/lib/swMessenger.ts
• src/lib/utilsStorage.ts
• src/lib/stores/preferencesManager.ts
• src/lib/stores/settingsMenuStore.ts
• src/lib/components/sse/SseHandler.svelte
• src/lib/components/layout/BackgroundServices.svelte
• Liaison SSE