fix(ContentUpdater): remove full-DB PRAGMA integrity_check (iOS 26 FTS5 teardown crash) by CraigBuckmaster · Pull Request #1534 · CraigBuckmaster/ScriptureDeepDive

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster · 2026-04-20T00:07:10Z

Why

TestFlight 1.0.7(20) segfaulted at launch. The crash is in SQLite's FTS5 teardown path during closeAsync, triggered by the PRAGMA integrity_check call we added in #1529.

Crash signature

EXC_BAD_ACCESS (SIGSEGV), 3.5s after launch, Thread 7:

exsqlite3_finalize ← garbage pointer deref
sqlite3Fts5IndexClose
fts5DisconnectMethod
fts5FreeVtab
sqlite3VtabUnlock
disconnectAllVtab
sqlite3Close
SQLiteModule.closeDatabase ← expo-sqlite iOS closeAsync

What's happening

Download completes → native File.downloadFileAsync writes temp file (fine, no memory spike — that fix from fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 is still working)
We open the temp DB with openDatabaseAsync(tempDbName)
We run SELECT content_hash FROM db_meta — passes
We run PRAGMA integrity_check — passes
verifyDb.closeAsync() → SQLite tears down FTS5 vtabs → finalize on stale pointer → segfault

integrity_check forces SQLite to load and validate every FTS5 index. scripture.db has FTS5 tables for verse search and people search. The combination of "FTS5 indexes loaded by integrity_check" + "expo-sqlite's closeAsync path on iOS 26" produces a use-after-free during teardown.

The fix

Remove the PRAGMA integrity_check block from downloadFullDb. Keep the content_hash check — that hash is baked into db_meta at build time over the full file contents, so a corrupt/truncated download fails at open or misses the row. Less rigorous than integrity_check, but avoids the teardown crash.

Documented as a TODO to revisit once expo-sqlite's FTS5 teardown is fixed upstream, or to migrate to streaming SHA-256 during the chunked write.

Intentionally NOT fixed here

The applyDelta path has the same PRAGMA integrity_check → closeAsync pattern at ContentUpdater.ts:234. Left as-is because:

First-launch users (the ones currently crashing) never hit the delta path
Delta integrity_check runs after transactional SQL mutation — more valuable there as a corruption check
If it ever crashes for a delta user, same fix applies; deferring avoids scope creep

A separate follow-up PR can address the delta-path integrity_check if it becomes a problem.

Tests

Removed returns failed when integrity_check fails after download (the tested code path no longer exists)
Removed dead integrity_check mocks from 5 full-DB tests where they'd never be consumed now
Delta-path tests untouched
35 ContentUpdater tests pass
Typecheck clean, lint 0 errors

Changes against PR #1529 that stay intact

Native download for large payloads (the real memory fix) ✓
content_hash verification ✓
Hydration ordering fix ✓
onComplete error surfacing ✓
Global JS error handler diagnostic ✓

Expected build 21 behavior

Three outcomes possible:

App reaches home screen cleanly — all the fix + diagnostic: native DB download, correct startup ordering, JS error handler #1529 fixes work, this was the last blocker. We revert the diagnostic in a small follow-up.
App crashes, Alert on relaunch — a different JS error fires; the diagnostic captures it.
App crashes silently — a different native-layer bug; crash log tells us where.

Supersedes

ClosesDefer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533 (which kept the integrity_check call; that's the root cause, not a solution)

Budget

~$4-6 EAS credits remain. This will be the final build of the month likely. If it works, great. If not, we have the diagnostic and crash logs to plan next month's work carefully.

…S5 teardown crash) ## The crash TestFlight 1.0.7(20) segfaulted 3.5s after launch — EXC_BAD_ACCESS on Thread 7, triggered by: exsqlite3_finalize sqlite3Fts5IndexClose fts5DisconnectMethod sqlite3VtabUnlock disconnectAllVtab sqlite3Close SQLiteModule.closeDatabase (expo-sqlite iOS, SQLiteModule.swift:489) The call chain: SDK 54 expo-sqlite's closeAsync → sqlite3Close → disconnectAllVtab → iterates every FTS5 vtab → fts5DisconnectMethod → fts5FreeVtab → sqlite3Fts5IndexClose → exsqlite3_finalize on a stale/freed statement pointer → crash. This is a teardown-path bug in FTS5 virtual-table cleanup that manifests specifically when: 1. The DB has FTS5 tables (scripture.db has them for verse/people search) 2. PRAGMA integrity_check was run on the connection (which loads and validates every FTS5 index, leaving them in a state that doesn't clean up correctly) 3. closeAsync is called on that connection Our full-DB download verification path added by #1529 (cherry-pick from #1531 commit 1) did exactly that: open temp DB, run content_hash check, run integrity_check, close. The integrity_check was the trigger. ## The fix Remove the PRAGMA integrity_check from the full-DB post-download verification path. Keep the content_hash check — it's sufficient validation: the hash was computed at build time over the full file contents, baked into db_meta at build time, and uploaded with the DB to R2. A corrupt/truncated download is overwhelmingly likely to fail at SQLite open (exception thrown before our read) or to miss the db_meta row entirely. This is less rigorous than integrity_check but avoids the teardown crash. TODO: re-add proper integrity verification once expo-sqlite's FTS5 teardown bug is resolved upstream, or migrate to streaming SHA-256 during the chunked write. ## Scope INTENTIONALLY LIMITED. The delta-apply path in applyDelta() has the same latent PRAGMA integrity_check → close pattern (~line 234). Left in place because: - Delta updates don't fire for first-launch users (the crash we're chasing is build-20 first-launch) - Delta integrity_check runs AFTER transactional SQL mutation, so it's more valuable as a corruption check than the post-download one was - Touching it expands scope beyond the confirmed crash site - If it ever DOES crash for a delta user, same fix applies; we'll know when we see the crash log ## Tests - Removed 'returns failed when integrity_check fails after download' (asserted behavior that no longer exists) - Removed 5 dead integrity_check mocks from full-DB tests where they were set up but would never be consumed now - Delta-path tests untouched (still exercise integrity_check) - 35 ContentUpdater tests pass (was 36, minus 1 removed) - tsc clean, lint 0 errors ## Build budget Build 21 will be the 2nd build on master since #1529 shipped. With no other changes, failure mode cascade from the cascade in #1529: - If Alert shows on relaunch → a JS error got past the fixes. Handler captured it. We see it next launch. - If app reaches home screen → all three crash causes fixed. We revert the diagnostic and ship. - If app still crashes silently → exceptionally rare; a different native-layer issue we haven't hit yet. ## References - Crash incident: 8C94684A-D8BE-45F5-B9A7-412450196AC4 - iOS Analytics log: CompanionStudy-2026-04-19-..-1.0.7(20) - Supersedes PR #1533 (which kept the integrity_check call in place)

github-actions · 2026-04-20T00:09:20Z

Test Results

✅ All tests passed

	Passed	Failed	Total
Tests	✅ 3431	❌ 0	3431
Suites	✅ 465	❌ 0	465

Coverage

Statements	Branches	Functions	Lines
—	—	—	—

⏱️ Duration: 78.8s

…tion ## Safety valve Previously, closeDatabaseConnection() swallowed errors from closeAsync and always set db = null, reporting success. If the native SQLite close actually failed (e.g., a statement still in flight), the subsequent file-swap would then move a temp file over a DB that SQLite still held open — leading to lock errors or, on iOS 26 with FTS5 tables, the teardown crash that PR #1534 just fixed for a different code path. Now closeDatabaseConnection() returns Promise<boolean>: - true : close succeeded OR db was already null (safe to swap) - false : closeAsync threw (NOT safe to swap) ContentUpdater.applyDelta and .downloadFullDb both check the return value. On false, they: 1. Log a warning 2. Cleanup any temp files (full-DB path) 3. Return { status: 'up_to_date' } The next OTA check will try again. Failing an update is strictly better than corrupting the DB file. ## Option B TODO Added a 30-line documentation block above ContentUpdaterService explaining the long-term architectural direction: defer-to-cold-start instead of close-and-reopen. Rationale: - The ONLY fully-safe time to swap the DB file is when no SQLite connection exists at all. - That condition naturally occurs during app cold-start, before initDatabase() runs. - Current close-and-reopen creates that condition artificially mid- session, which is fragile (stale getDb() refs, in-flight query errors). - Defer-to-cold-start trades 'updates land immediately' for 'updates land on next launch', which is acceptable for scholarly content updates. This PR ships phase 1 (close-and-reopen with safety valve). Phase 2 (full cold-start-swap architecture) is a separate project tracked as a TODO comment. PR #1533's original 'defer OTA when live DB open' idea informed this direction but cannot be implemented as-is (the DB is always open after startup, so defer-on-live-db would mean updates never fire). ## Tests - Added 2 focused tests covering the safety valve: - aborts delta apply when live DB close fails - aborts full DB swap when live DB close fails Both assert status=up_to_date AND that the swap/backup was NOT attempted (mockFileOps.move / copy). - Updated mock default return values for closeDatabaseConnection from undefined to true (matches new signature). - 41 ContentUpdater tests pass (was 39 + 2 new). - Broader sweep: 30 suites / 454 tests pass. - Typecheck clean, lint 0 errors. ## Not in scope Cold-start-swap implementation is out of scope for this PR — that's a separate project. This PR keeps #1532's original close-and-reopen strategy and hardens it; it does not replace it.

CraigBuckmaster mentioned this pull request Apr 20, 2026
Defer OTA when live DB open, use native download for large DBs, and reorder app init/hydration #1533
Closed

CraigBuckmaster merged commit 39a9590 into masterApr 20, 2026
6 checks passed

CraigBuckmaster deleted the fix/remove-integrity-check-fts5-crash branch April 20, 2026 00:17