fix(cli): surface lock-acquisition errors and silence Emscripten Aborted() spam#128
Merged
colbymchenry merged 2 commits intoMay 8, 2026
Conversation
…ted() spam
Two unrelated cosmetic but actively misleading bugs that surface when
the indexer is under load.
1) printIndexResult fell through to "No files found to index" whenever
the IndexResult had filesIndexed=0 AND filesErrored=0. The
lock-acquisition path returns success:false with a generic
"Could not acquire file lock" entry in result.errors[] (severity
'error'), but filesErrored counts only file-level parse failures,
so the user saw "No files found to index" — actively wrong.
Add a top-of-function check for the !success && !hasErrors case
that surfaces the first severity:'error' message instead.
2) parse-worker.ts let Emscripten's stderr "Aborted()" lines (plus
their "Build with -sASSERTIONS for more info" follow-ups) leak to
the parent's terminal whenever a WASM tree-sitter parser crashed
on a pathological file. Even after the JS layer caught and recovered,
the user saw dozens of `Aborted()` lines spammed to stderr. Install
a stderr filter at worker startup that drops only those specific
Emscripten internal lines; everything we log ourselves passes
through unchanged.
Verified live against ollama/ollama@v0.22.0:
- second concurrent `codegraph index` now shows
"Could not acquire file lock - another process may be indexing"
instead of "No files found to index"
- WASM-crash-prone re-index produced 0 Aborted() lines (down from 68+).
…docs Two reviewer findings on PR colbymchenry#128: - printIndexResult: when result.success is false but result.errors contains no severity:'error' entry (degenerate case but possible if the result shape ever drifts), the find() returned undefined and the previous if-guard fell through to the misleading 'No files found to index' branch. Now always surfaces a clear failure message via clack.log.error, defaulting to 'Indexing failed — no further details available' when no specific error is in the errors list. - parse-worker stderr filter: callback handling was already correct but the comment didn't document it; expand the comment to spell out the Writable-stream-contract obligation, the per-call match semantics (split-chunk caveat), and the substring-exactness trade-off so future readers understand the deliberate trade-offs.
andreinknv
added a commit
to andreinknv/codegraph
that referenced
this pull request
Apr 28, 2026
andreinknv
added a commit
to andreinknv/codegraph
that referenced
this pull request
Apr 29, 2026
Adds Steps K-O to walk the new PRs in dependency order: K: bug-fix wave (clean): colbymchenry#128, colbymchenry#129 L: resolution + search: colbymchenry#130 (resolve), colbymchenry#131 (resolve) M: extraction edges: colbymchenry#134 (resolve) N: biomarker stack: colbymchenry#132, colbymchenry#133 (both resolve, on top of colbymchenry#125) O: search advanced: colbymchenry#135 (resolve, on top of colbymchenry#131) Also flips colbymchenry#125 from merge_clean to merge_resolve - it now hits a queries.ts conflict after the Phase-4 stack lands (colbymchenry#111/colbymchenry#112/colbymchenry#123/colbymchenry#124 all extend the same QueryBuilder surface, so colbymchenry#125's biomarker columns no longer apply cleanly without a resolution). Validated end-to-end against colbymchenry/main HEAD: script ran clean through all 43 PRs, npm run build succeeded, full test suite reports 877/877 passing (was 829 before this wave: +48 from new tests added by the new PRs plus the reviewer-driven follow-ups).
Owner
|
Reviewed and merging. The stderr filter is well-scoped to the parse-worker process (no risk of swallowing main-process output) and the comments explicitly call out the per-call-match and substring-exactness caveats — exactly the right things to flag. The CLI fix only kicks in for the precise misreported state. Auto-merges with main, full suite passes. Thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two small, unrelated CLI cosmetic bugs that show up when the indexer is under load. Both are actively misleading rather than just noisy.
1. Lock-acquisition error hidden behind "No files found to index"
printIndexResultfalls through to'No files found to index'wheneverfilesIndexed === 0 && filesErrored === 0. The lock-acquisition path inindexAll/syncreturns{ success: false, errors: [{ message: 'Could not acquire file lock ...', severity: 'error' }] }, butfilesErroredcounts only file-level parse failures — so the lock-failure message never gets shown. The user sees "No files found to index" while another indexer is actively running.Added a check at the top of
printIndexResultthat surfaces the first generic error whenresult.success === false.2. Emscripten Aborted() spam leaking to the parent terminal
When tree-sitter WASM crashes on a pathological file (large generated C/C++ headers, etc.), the parse worker correctly catches the
RuntimeError: memory access out of boundsand exits with code 1 — but Emscripten itself printsAborted()(and a follow-upBuild with -sASSERTIONS for more infoline) directly to stderr before the JS handler runs. Those lines leak to the parent's terminal even though the JS layer recovers cleanly. Re-indexing a repo with WASM-prone files produces dozens ofAborted()lines.Installed a startup-time
process.stderr.writefilter inparse-worker.tsthat drops only those two specific Emscripten internal lines. Everything we log ourselves (viaconsole.*/parentPort.postMessage) passes through unchanged.Test plan
Verified live against ollama/ollama@v0.22.0 (1.2 GB repo, 1,179 indexed files including vendored llama.cpp / MLX-C):
codegraph indexwhile another indexer is running now showsCould not acquire file lock - another process may be indexing(was: "No files found to index")Aborted()lines (was: 68+)npx tsc --noEmitpassesnpm run buildsucceeds🤖 Generated with Claude Code