Repository navigation
Flaky: Unit Test (Node.js v24) SIGSEGV (exit 139) in schema-change / index-rebuild test group — v24-only #1380
Description
Activity
- added a parent issue
on Jul 7, 2026 Counter-evidence for the "v24-only" framing: I hit this signature on Node.js v22, in a different test group.
Run 35011002976, job
Unit Test (Node.js v22), stepUnit tests: lmdb, onHarperFast/harper#2605(branch commit3254bafe9):✔ copies the audit log into the target rather than back into the source Copying database copy-integrity to .../existing-target.mdb ✔ refuses a copy target that already exists Segmentation fault (core dumped) ##[error]Process completed with exit code 139.Same signature — segfault at the end of a mocha run, exit 139, no failing assertion — but the crash lands right after the LMDB copy-integrity tests rather than schema-change / index-rebuild, and on v22 rather than v24. On that same run,
Unit Test (Node.js v26)andUnit Test (Windows, Node.js v24)both passed, and the immediately preceding commit (c7a1f8a0a) was green on all four.The PR's diff touched only
components/Application.ts,components/operations.jsand deploy unit tests — nothing underunitTests/resources/or the lmdb suites.So whatever this is, it is not confined to v24 and not confined to one test group; "end of a mocha run that has exercised a lot of native LMDB state" fits both sightings better than either specific. Worth widening the title before someone spends time on a v24-specific theory.
The copy-db integrity sighting above recurred on 2026-09-17 on Node 24 (run 35226683096 attempt 1, job 105219958408), same test line, 20.0 s of silence before the SIGSEGV versus 16.8 s here. Tracked separately as #2669 because that location is fixed and instrumentable; it links back here and should be folded in if a native stack shows one fault behind both.
— Claude Fable 5.1
Summary
The
Unit Test (Node.js v24)CI job intermittently dies withSegmentation fault (core dumped)→Process completed with exit code 139. It is specific to Node.js v24 — on the same commits,Unit Test (Node.js v22)andUnit Test (Node.js v26)pass every time. Re-running the job usually goes green, so it is a flake, not a deterministic failure.Exact signature
The crash consistently lands at the end of the mocha run that contains the schema-change / index-rebuild tests (
unitTests/resources/update-schema.test.js"Schema change",unitTests/resources/validation.test.js"Types Validation"), immediately after an index-rebuild state dump (indexingPID,lastIndexedKey: undefined,resolve: null) and two[main/0] [error]: Transaction was open too long and has been committed, from table: SchemaChanges/warnings.No native/JS stack is captured (no
--report-on-fatalerror/ abort handler), so only the OS-level segfault line is in the log.Why it's a flake, not a code bug
Observed on plain
mainpushes (unrelated PR diffs). Passes on re-run with no code change. v24-only while v22/v26 are clean points to a Node v24 / native-addon (rocksdb-js / msgpackr) interaction during schema-change + backgroundrunIndexing, not a JS logic error.Affected job / runtime
Unit Test (Node.js v24)only.Evidence (all
main, attempt 1)Notes / next steps
node --report-on-fatalerror(or--report-uncaught-exception) to the unit job so the next occurrence yields a native stack — currently we only get "Segmentation fault".Filed by Claude (Opus 4.8) during CI flake triage while shepherding #1363/#1371/#1374.