fix(pipeline): restore parallel CALLS resolution for LSP-unresolvable targets#1106
Merged
Conversation
… targets The parallel resolver dropped a CALLS edge whenever the LSP produced a resolution whose callee_qn was not a node in the graph buffer: the registry fallback lived in an else that ran only when NO LSP resolution existed, so an LSP-with-unresolvable-target left res empty and the edge was discarded outright. The sequential pass falls THROUGH to the registry resolver in the same situation. This diverged the two pipelines on the exact intersection the reporter identified (#1085): a JSX component imported through a tsconfig paths alias. The TS LSP resolves the element ref to an alias-path QN that never matches a def node, so lsp_target is NULL and the parallel path dropped it — while sequential resolved it via the import_map / unique_name registry path. On a Next.js repo this silently removed ~21% of the call graph (every alias-imported JSX composition edge), and the parallel path is the default above 50 files, so the default index was the broken one. The fix runs the registry fallback whenever the LSP did not yield a gbuf-resolvable target, matching the sequential fall-through and restoring seq/parallel parity. Reproduce-first: calls_jsx_component_via_tsconfig_alias_parallel_issue1085 indexes the alias+JSX shape through the parallel path (et_index_parallel pads past the 50-file threshold) and asserts the CALLS edges land on the component. RED before (0 edges), GREEN after. Closes #1085 Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
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
1 participant
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.
Closes #1085
Root cause (reporter's diagnosis confirmed and pinned)
The parallel resolver dropped a CALLS edge whenever the LSP produced a resolution whose
callee_qnwasn't a node in the graph buffer. The registry fallback lived in anelsethat ran only when no LSP resolution existed — so an LSP-with-unresolvable-target leftresempty and the edge was discarded. The sequential pass falls through to the registry resolver in exactly that case.The intersection where they diverge: a JSX component imported through a tsconfig
pathsalias. The TS LSP resolves<KpiCard>to an alias-path QN that never matches a def node, solsp_targetis NULL; parallel dropped it, sequential resolved it via the import_map/unique_name registry path. On a Next.js repo this silently removed ~21% of the call graph (every alias-imported JSX composition edge), and since the parallel path is the default above 50 files, the default index was the broken one — "who renders<KpiCard>?" returned nothing.Fix
Run the registry fallback whenever the LSP didn't yield a gbuf-resolvable target (no LSP resolution or resolution-with-missing-target), matching the sequential fall-through and restoring seq/parallel parity. LSP still takes precedence when its target is in the graph.
Reproduce-first
calls_jsx_component_via_tsconfig_alias_parallel_issue1085indexes the alias+JSX shape through the parallel path (et_index_parallelpads past the 50-file threshold — the bug is invisible below it, which is why prior synthetic corpora missed it) and asserts the CALLS edges land on the component. RED before (0 edges), GREEN after (both renders resolve). Verified my minimal 55-file fixture goes 0 → 55 edges with the fix.Verification
Full local suite green under a normal fd limit (6328 passed, 1 skipped). Note: on macOS the local full suite can hit the 256-fd default late in the run (cumulative across ~250 index calls);
ulimit -n 4096clears it and Linux CI's 1024+ default has ample headroom — this is unrelated to the change (confirmed: clean main + one extra parallel test tips the same limit). lint-ci clean.