HarperFast / HarperFast/harper
Flaky: Unit Test (Node.js v24) SIGSEGV (exit 139) in schema-change / index-rebuild test group — v24-only
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 200
Description
## Summary
The `Unit Test (Node.js v24)` CI job intermittently dies with `Segmentation 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)` and `Unit 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
```
Segmentation fault (core dumped)
##[error]Process completed with exit code 139.
```
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 `main` pushes (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 + background `runIndexing`, not a JS logic error.
## Affected job / runtime
`Unit Test (Node.js v24)` only.
## Evidence (all `main`, attempt 1)
- run 27718772847 / job 81998436331
- run 27718421204 / job 81997233958
- run 27696972188 / job 81922701975
## Notes / next steps
- Add `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".
- Distinct from #828 (CursorWrap::close on rapid drop_table+drop_schema), #1370 (decode-path heap corruption), and #414 (LMDB caching tests) — different trigger (schema-change + reindex) and v24-specific.
---
_Filed by Claude (Opus 4.8) during CI flake triage while shepherding #1363/#1371/#1374._
Contributor guide
Research direction
Start by reviewing the Unit Test (Node.js v24) job and the schema-change cases in unitTests/resources/update-schema.test.js and unitTests/resources/validation.test.js. Reproduce or rerun the affected job with fatal-error reporting enabled, then use the resulting native stack to isolate the v24 crash around index rebuilding. Done means the cause is identified and the flake is fixed or a focused diagnostic change is validated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- ci-cd, databases, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100