You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Launch-to-crash delta matched the R2 download window. Build (11) (without #1500) was fine. Craig confirmed #1501 was NOT in the crashing bundle, so the only new code between (11) and (12) was #1500 + #1499 (the map probe fix — innocent, only runs when the Map tab mounts).
What was investigated and ruled out
Audit of the 5 files PR #1500 touched (AmicusPeekSheet.tsx, PeekMiniConversation.tsx, promotePeekToThread.ts, and their tests) against the post-download init path:
Suspected cause
Finding
New user.db migration with bad SQL
Not present — #1500 didn't touch userDatabase.ts or add a migration
New @/db/userMutations / TurboModule calls on mount
Not present — promotePeekToThread is only invoked from the "Continue in Amicus tab →" press handler, never at mount
New provider wrapping App.tsx
Not present — no changes to App.tsx, navigation root, or any provider
Eager mount-time effect hitting the DB
Not present — new useState/useCallback/useEffect additions in AmicusPeekSheet are all pure state
The AmicusFab at App.tsx:230 is already a sibling of NavigationContainer and was calling useNavigation + useNavigationState in build (11) without issue, so this isn't a net-new risk
Circular import from promotePeekToThread.ts
None — only type-only import of PeekMessage
Nothing in the audit surfaced an obvious boot-path crash cause. Since the brief prioritizes getting the app launching over a diagnostic fix, we reverted.
Re-land plan
Before re-landing:
Reproduce the crash on-device with feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500 applied — get a symbolicated crash log. The Xcode/Sentry stack from build (12) points at RCTTurboModule.mm:441 but doesn't name the module. Capturing the failing selector will pinpoint which TurboModule is being invoked with bad args.
Test the hot path in release mode — eas build --profile production → on-device install. Release-mode bundling + Hermes + New Arch often behave differently from Jest, and feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500's tests are all Jest-level.
Sanity-check the R2 handoff bridge — since the crash is timing-correlated with the download completing, the suspect may be an interaction between DbDownloadScreen.onComplete (which triggers initDatabase() again + setDbStatus('ready')) and the main tree mounting. Verify nothing feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500 added runs eagerly on first mount of AppShell or AmicusFab.
Consider moving the CTA logic out of AmicusPeekSheet — if the re-audit can't isolate the cause, split the service call into a screen-level handler invoked on press only, so module-scope cost is zero.
Tracking issue for re-landing the peek→tab handoff feature that was backed out in #1503 (revert of #1500).
Why it was reverted
TestFlight build 1.0.5 (12) — first build to include #1500 — crashed on first launch immediately after the R2
scripture.dbdownload completed, with:Launch-to-crash delta matched the R2 download window. Build (11) (without #1500) was fine. Craig confirmed #1501 was NOT in the crashing bundle, so the only new code between (11) and (12) was #1500 + #1499 (the map probe fix — innocent, only runs when the Map tab mounts).
What was investigated and ruled out
Audit of the 5 files PR #1500 touched (
AmicusPeekSheet.tsx,PeekMiniConversation.tsx,promotePeekToThread.ts, and their tests) against the post-download init path:userDatabase.tsor add a migration@/db/userMutations/ TurboModule calls on mountpromotePeekToThreadis only invoked from the "Continue in Amicus tab →" press handler, never at mountApp.tsxApp.tsx, navigation root, or any provideruseState/useCallback/useEffectadditions inAmicusPeekSheetare all pure stateuseNavigation<NavigationProp<ParamListBase>>()call outsideNavigationContainerAmicusFabatApp.tsx:230is already a sibling ofNavigationContainerand was callinguseNavigation+useNavigationStatein build (11) without issue, so this isn't a net-new riskpromotePeekToThread.tstype-only import ofPeekMessageNothing in the audit surfaced an obvious boot-path crash cause. Since the brief prioritizes getting the app launching over a diagnostic fix, we reverted.
Re-land plan
Before re-landing:
RCTTurboModule.mm:441but doesn't name the module. Capturing the failing selector will pinpoint which TurboModule is being invoked with bad args.eas build --profile production→ on-device install. Release-mode bundling + Hermes + New Arch often behave differently from Jest, and feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500's tests are all Jest-level.DbDownloadScreen.onComplete(which triggersinitDatabase()again +setDbStatus('ready')) and the main tree mounting. Verify nothing feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500 added runs eagerly on first mount ofAppShellorAmicusFab.AmicusPeekSheet— if the re-audit can't isolate the cause, split the service call into a screen-level handler invoked on press only, so module-scope cost is zero.Branch / commit refs
d1ce303(feature) /11488ab(merge)/cc @CraigBuckmaster