[Mobile] Vérification de mise à jour à chaque ouverture de l'app #106

Closed
opened 2026-09-08 00:47:53 +02:00 by kyuno · 0 comments
Owner

Résumé

La vérification de nouvelle version (bannière issue #66 / PR #69) ne se déclenche pas de façon fiable à l'ouverture de l'app : un utilisateur non connecté ne la déclenche jamais, alors que le back suppose l'inverse.

Contexte (trouvé en auditant le code, pas supposé)

  • apps/web/src/features/app-update/useAppUpdateCheck.ts : l'useEffect(…, []) lance backgroundCheck() au montage (garde if (!Capacitor.isNativePlatform()) return;) et enregistre un listener App.addListener("appStateChange", …) (re-check au retour en premier plan). Sa JSDoc dit qu'il est « safe to call unconditionally from AppLayout, which renders on both platforms ».
  • Mais <UpdateBanner /> (seul appelant du hook) n'est monté que dans apps/web/src/layouts/AppLayout.tsx (<main>), et AppLayout est derrière RequireAuth. Un utilisateur non connecté sur l'app native voit LandingPage → AppLayout n'est jamais monté → aucune vérification tant qu'on n'est pas connecté.
  • Le back l'attend pourtant : apps/api/src/modules/mobile/mobile.routes.ts — commentaire « the native update check (issue #66) runs on every app start, session or not ».
  • Bruit annexe : throttle 6 h persisté (CHECK_INTERVAL_MS, LAST_CHECKED_KEY dans @capacitor/preferences, survit au redémarrage) → une réouverture < 6 h ne fait aucun appel réseau. Et un APK ad-hoc (hors CI) a versionName = "1.0", que version-compare.ts parseVersion (/^v?(\d+)\.(\d+)\.(\d+)$/) rejette → toujours « à jour ».

Contenu attendu

La vérification automatique doit tourner à chaque ouverture de l'app, connecté ou non — déclencher useAppUpdateCheck() / monter <UpdateBanner /> à un endroit rendu pour toutes les routes (p. ex. dans App.tsx autour de <Routes>, ou un petit shell toujours monté), pas seulement dans AppLayout. Conserver la garde !isNativePlatform() et le throttle 6 h.

Vérifier au passage que la fenêtre de throttle et le parsing de versionName sont acceptables (throttle éventuellement réduit ; parseVersion tolérant à "1.0").

Dépendances

Aucune ; réutilise le hook existant tel quel.

## Résumé La vérification de nouvelle version (bannière issue #66 / PR #69) ne se déclenche pas de façon fiable à l'ouverture de l'app : un utilisateur **non connecté** ne la déclenche jamais, alors que le back suppose l'inverse. ## Contexte (trouvé en auditant le code, pas supposé) - `apps/web/src/features/app-update/useAppUpdateCheck.ts` : l'`useEffect(…, [])` lance `backgroundCheck()` au montage (garde `if (!Capacitor.isNativePlatform()) return;`) et enregistre un listener `App.addListener("appStateChange", …)` (re-check au retour en premier plan). Sa JSDoc dit qu'il est « safe to call unconditionally from `AppLayout`, which renders on both platforms ». - Mais `<UpdateBanner />` (seul appelant du hook) n'est monté que dans `apps/web/src/layouts/AppLayout.tsx` (`<main>`), et `AppLayout` est **derrière `RequireAuth`**. Un utilisateur non connecté sur l'app native voit `LandingPage` → `AppLayout` n'est jamais monté → **aucune vérification tant qu'on n'est pas connecté**. - Le back l'attend pourtant : `apps/api/src/modules/mobile/mobile.routes.ts` — commentaire « the native update check (issue #66) runs on every app start, session or not ». - Bruit annexe : throttle 6 h persisté (`CHECK_INTERVAL_MS`, `LAST_CHECKED_KEY` dans `@capacitor/preferences`, survit au redémarrage) → une réouverture < 6 h ne fait aucun appel réseau. Et un APK ad-hoc (hors CI) a `versionName = "1.0"`, que `version-compare.ts` `parseVersion` (`/^v?(\d+)\.(\d+)\.(\d+)$/`) rejette → toujours « à jour ». ## Contenu attendu La vérification automatique doit tourner **à chaque ouverture de l'app, connecté ou non** — déclencher `useAppUpdateCheck()` / monter `<UpdateBanner />` à un endroit rendu pour toutes les routes (p. ex. dans `App.tsx` autour de `<Routes>`, ou un petit shell toujours monté), pas seulement dans `AppLayout`. Conserver la garde `!isNativePlatform()` et le throttle 6 h. Vérifier au passage que la fenêtre de throttle et le parsing de `versionName` sont acceptables (throttle éventuellement réduit ; `parseVersion` tolérant à `"1.0"`). ## Dépendances Aucune ; réutilise le hook existant tel quel.
kyuno added the
Medium
bug
planned
labels 2026-09-08 00:47:53 +02:00
kyuno closed this issue 2026-09-08 03:41:38 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kyuno/batchCooking#106
No description provided.