Skip to content

Re-land #1464 peek → Amicus tab handoff (reverted in #1503) after root-cause investigation #1504

@CraigBuckmaster

Description

@CraigBuckmaster

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.db download completed, with:

EXC_CRASH (SIGABRT)
facebook::react::ObjCTurboModule::performVoidMethodInvocation
  (RCTTurboModule.mm:441)
__cxa_rethrow → objc_exception_rethrow → _objc_terminate → abort

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
useNavigation<NavigationProp<ParamListBase>>() call outside NavigationContainer 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:

  1. 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.
  2. Bisect on a physical device — apply feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500 commit-by-commit on top of (11) to confirm which of the 5 file changes triggers the crash, instead of assuming it's feat(ai-partner): continue-in-tab handoff from peek (#1464) #1500 as a whole.
  3. Test the hot path in release modeeas 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.
  4. 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.
  5. 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.

Branch / commit refs

/cc @CraigBuckmaster

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions