fix(cli): surface lock-acquisition errors and silence Emscripten Aborted() spam#9
Open
mschreib28 wants to merge 2 commits into
Open
fix(cli): surface lock-acquisition errors and silence Emscripten Aborted() spam#9mschreib28 wants to merge 2 commits into
mschreib28 wants to merge 2 commits into
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.
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\n\nTwo small, unrelated CLI cosmetic bugs that show up when the indexer is under load. Both are actively misleading rather than just noisy.\n\n### 1. Lock-acquisition error hidden behind "No files found to index"\n\n
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.\n\nAdded a check at the top ofprintIndexResultthat surfaces the first generic error whenresult.success === false.\n\n### 2. Emscripten Aborted() spam leaking to the parent terminal\n\nWhen tree-sitter WASM crashes on a pathological file (large generated C/C++ headers, etc.), the parse worker correctly catches theRuntimeError: 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.\n\nInstalled a startup-timeprocess.stderr.writefilter inparse-worker.tsthat drops only those two specific Emscripten internal lines. Everything we log ourselves (viaconsole.*/parentPort.postMessage) passes through unchanged.\n\n## Test plan\n\nVerified live against ollama/ollama@v0.22.0 (1.2 GB repo, 1,179 indexed files including vendored llama.cpp / MLX-C):\n\n- [x]codegraph indexwhile another indexer is running now showsCould not acquire file lock - another process may be indexing(was: "No files found to index")\n- [x] Re-index of a repo that had previously triggered WASM-abort lines: 0Aborted()lines (was: 68+)\n- [x]npx tsc --noEmitpasses\n- [x]npm run buildsucceeds\n\n🤖 Generated with Claude Code\nCopied from colbymchenry/codegraph#128