Reproduire le crash natif Fabric au retour du réseau sur Android #310
Description
Contexte
Epic : #8
Maquette : sans objet — crash natif, aucun changement d'écran
Architecture-Technique › PostHog et Sentry par environnement · E-02
Découverte de CODE pendant la recette de la PR #302 (Inbox, 2026-10-06) : un crash natif Android vu une fois, SIGSEGV dans facebook::react::MountingCoordinator::pullTransaction (Fabric, React Native 0.86.3), sur l'émulateur Medium_Phone API 34, juste après le rétablissement du Wi-Fi et des données, la recherche E-02 ouverte. Trois essais de la même séquence n'ont rien reproduit. Peut venir de React Native plutôt que de l'app.
Ticket à reproduire : il se livre par un diagnostic, avec ou sans correctif.
Comportement attendu
- Chercher à reproduire : séquence relevée (coupure puis retour du réseau, recherche ouverte, saisie en cours ou non, autres écrans), sur émulateur et sur le Redmi Note 9 (build
preview), et chercher l'événement dans Sentry staging. - Si reproduit : cause identifiée et corrigée dans l'app, ou contournement et lien vers l'issue React Native si le défaut est en amont.
- Si non reproduit : le dire avec les essais faits ; MANAGER décide de fermer ou de garder le ticket en surveillance.
En surveillance (MANAGER, 2026-10-13)
Non reproduit par CODE en 31 essais sur émulateur. Le ticket reste ouvert en surveillance, labellisé human : il ne reste que les essais sur appareil et la recherche Sentry, par Paul au build #367. CODE ne le prend pas.
- Rien sur appareil ni dans Sentry : MANAGER ferme le ticket sans PR, sur la parole de Paul.
- Crash reproduit ou trouvé dans Sentry : MANAGER retire
human, remetstatus:readyavec la séquence relevée, et CODE reprend le ticket. Piste à regarder en premier : layout animations de Reanimated (voir Évaluer la montée de Reanimated 4.5.x #375).
Critères d'acceptation
- Au moins 10 essais de la séquence sur émulateur, relevés en commentaire — 31 essais, 0 crash (diagnostic de CODE, 2026-10-13)
- Au moins 10 essais de la séquence sur appareil (Redmi Note 9, build
preview), relevés en commentaire — 10 essais, aucun plantage, déclarés par Paul le 2026-10-13 sur le buildc829f165(Lancer le build preview Android depuis main e152dd4 et le recetter sur appareil #367) - Recherche de
pullTransactiondans les issues React Native et Reanimated connues, résultat en commentaire (même diagnostic) - Recherche de
pullTransactiondans Sentry staging, résultat en commentaire — recherche faite par Paul le 2026-10-13 : rien de nouveau trouvé, sans certitude (« peut-être mal cherché ») - Si reproduit : correctif ou contournement dans une PR, crash absent sur 10 essais après — sans objet : non reproduit
Activity
IlanAMG commentedon Oct 13, 2026
Chef de projet (point du 2026-10-13) : jalon v0.2 → v0.6. v0.2 est échu depuis le 07/10 et ses P0 sont livrés ; ce ticket de finition de la découverte ne conditionne pas la suite. v0.6 (25/11) regroupe la finition avant le lancement, pour laisser la place à v0.3 (fiche, orchestration, compte), dont aucun P0 n'a encore démarré. Priorité inchangée.
PaulThiberville commentedon Oct 13, 2026
🔨 Démarrage — plan :
Medium_Phone(API 34), depuismainàe152dd4, API locale ;svc wifi/svc data, ou mode avion) puis retour, avec la recherche E-02 ouverte (avec ou sans saisie en cours), et sur d'autres écrans ;adb logcatet/data/tombstonescapturés à chaque essai ;pullTransactiondans Sentry staging (si un accès est disponible dans l'environnement) et dans les issues React Native ;Fixes #310; sinon : relevé des essais ici, et Status remis à « Prêts » pour décision de MANAGER.preview) revient à Paul : je n'y ai pas accès.PaulThiberville commentedon Oct 13, 2026
🔎 Diagnostic : crash non reproduit (31 essais sur émulateur, 0 crash)
Environnement : émulateur
Medium_Phone(API 34, image Google Play, x86_64), dev buildapp.widoodu 2026-10-09 (natif identique àmain: les seuls changements depuis sont des dépendances de dev, svgr), JS servi par Metro depuismainàe152dd4, API locale. Position de test : République. RN 0.86.3, Reanimated 4.5.1, worklets 0.10.1, Expo 57.0.24.Méthode : un script rejoue chaque séquence. Coupure par
svc wifi disable+svc data disable, ou par le mode avion (cmd connectivity airplane-mode), puis retour du réseau. Après chaque essai, trois contrôles : PID de l'app inchangé,logcat(main, system, crash) sansFatal signal/SIGSEGV/pullTransaction/FATAL EXCEPTION, et aucune entréeTOMBSTONEoudata_app_native_crashdansdumpsys dropbox. L'image est en mode production, donc sans root :/data/tombstonesn'est pas lisible directement, et dropbox reçoit une copie de chaque tombstone. Contrôles préalables : la bascule hors ligne s'affiche dans E-02 (« Hors connexion · recherche indisponible »), et après le retour du réseau les résultats réapparaissent avec leur animation d'entrée (Animated.View enteringdansSearchPanel).Total : 31 essais sur émulateur, 0 crash, 0 tombstone, buffer
crashde logcat vide.Appareil (Redmi Note 9, build
preview) : pas fait. L'appareil n'était pas à la disposition de l'agent. Les 10 essais sur appareil reviennent à Paul, au prochain buildpreview.Limite de la méthode : l'API locale passe par
adb reverseet reste joignable pendant une coupure ; seuls les services distants (Mapbox, Sentry) et l'état réseau vu par l'app sont réellement coupés. Le buildpreviewsur appareil, qui appelle l'API de staging, n'a pas cette limite.Recherches
sentry-clini jeton d'API ; le DSN sert seulement à envoyer des événements). RecherchepullTransactiondans Sentry staging à faire par Paul ou Ilan.react/react-native, 19 issues pourpullTransaction) : aucune issue ouverte qui corresponde à un SIGSEGV Android sur 0.86.enableMountingCoordinatorPullModelAndroidn'y existe pas encore, et Android y est en push model, oùpullTransactions'appelle depuis le thread du commit (JS ou fond).MountingCoordinator, déjà présents en 0.86.MountingOverrideDelegate, donc s'exécutent dansMountingCoordinator::pullTransaction. L'app en utilise (enteringdansSearchPanel,RouteSummary,MapControls,SelectedRoute), etSearchPanelremonte sa vue de résultats animée à chaque nouvelle requête (key={input.settled}), exactement ce qui se passe au retour du réseau.FabricUIManagerBinding::schedulerDidFinishTransaction→MountingCoordinator::pullTransaction→ SIGSEGV) sur Expo 57 / RN 0.86.3, mais à partir de Reanimated 4.7.0, sans reproduction.ENABLE_SHARED_ELEMENT_TRANSITIONS: false) et la 4.5.1 installée ne contient pas ce correctif.Conclusion
Non reproduit en 31 essais sur émulateur, sans signal dans les issues connues sur la combinaison RN 0.86.3 + Reanimated 4.5.1. Le crash vu une fois reste compatible avec une course dans le proxy de layout animations de Reanimated, mais rien ne permet de l'affirmer ni de justifier un correctif dans l'app. Pas de PR. Le Status repasse à « Prêts » ; à MANAGER de décider de fermer le ticket ou de le garder en surveillance (Sentry staging et essais sur appareil).
IlanAMG commentedon Oct 13, 2026
Chef de projet (2026-10-13, suite) : jalon v0.6 retiré, ticket remis au backlog, priorité inchangée. Orientation retenue ce jour avec Ilan et Paul : séparer le périmètre du temps, avec des sprints d'une semaine (champ Sprint du Project, à partir du 19/10). Un ticket de finition découvert en cours de route va au backlog et entre dans un sprint selon sa priorité. Le placer en v0.6 ce matin faisait déborder son epic sur une date sans rapport avec le travail.
PaulThiberville commentedon Oct 13, 2026
✅ Clôture sans PR (MANAGER, 2026-10-13), selon la règle « En surveillance » du ticket, sur la déclaration de Paul dans la session.
previewAndroidc829f165(commite152dd4) : 10 essais de la séquence « réseau coupé puis rétabli pendant la recherche E-02 », aucun plantage.pullTransactionfaite par Paul, « rien de nouveau, mais peut-être mal cherché » : rien trouvé, sans certitude.Le crash n'a été vu qu'une fois (émulateur, 2026-10-06). La piste Reanimated (layout animations, SIGSEGV connu dans
MountingCoordinator::pullTransactionen 4.7.0) reste suivie par #375. S'il réapparaît (appareil ou Sentry), rouvrir ce ticket avec la séquence relevée. Recette complète : #367 (comment)