Native/WASM engine parity divergence + CLI -f arg-marshaling crash, affecting all open PRs' CI

[carlos-alm]

Discovered while sweeping all 10 open PRs (#2119-#2129) on 2026-07-19/20. Every open PR showed the same "Test Node 22" / "Engine parity" CI failures regardless of what the PR actually changed — including trivial, unrelated changes like a GitHub Actions version bump (actions/setup-node, actions/setup-go, anthropics/claude-code-action) and a Gleam-only grammar bump (tree-sitter-gleam). That ruled out any of those PRs' own diffs as the cause.

Five independent sweep agents, working in isolated worktrees on unrelated PRs, each re-ran the failing jobs once and independently confirmed the exact same failure signatures reproduce deterministically — this is not occasional flakiness, it's consistently reproducible given the current main state (or very close to it). Two distinct bugs were identified:

Bug 1: Native vs WASM engine parity divergence

Both Test Node 22 and Engine parity jobs fail with real content/count mismatches between the native (Rust) and WASM engines, spanning multiple languages:

• tests/integration/build-parity.test.ts — csharp Repository fixture:
  • "produces identical edges": native vs WASM produce 77 vs 79 edges (a real count mismatch, not just ordering)
  • "produces identical roles": UserService.UserService (a constructor) classified as role core by native but dead-ffi by WASM
  • Same test file also shows mismatches on the sample-project (JS) fixture ("produces identical nodes/roles")
• tests/engines/ast-parity.test.ts — ast_nodes row-count parity:
  • typescript: WASM=2, Native=4
  • php: WASM=4, Native=6
• tests/engines/parity.test.ts — multiple "must agree between engines" callback-gating assertions fail for JS/TS (e.g. "callback gating must agree between engines", "identifier-arg callback gating", "Array.from positional callback gating", "inline object-literal dispatch table", "identifier args to user-defined higher-order functions recognized via parameter type")
• tests/unit/call-resolver.test.ts, tests/integration/queries.test.ts, tests/parsers/ast-nodes.test.ts also showed resolver-recall/parity assertions failing well below 100% on at least one PR's run (build(deps-dev): bump commit-and-tag-version from 12.7.3 to 13.0.0 #2123) — may be the same root cause or a related symptom; needs isolation.

Per this repo's own architecture principle ("Both engines must produce identical results. If they diverge, the less-accurate engine has a bug — fix it, don't document the gap"), this is a real bug in whichever engine is wrong, not acceptable drift.

Investigation lead (unconfirmed): commit 156004ac / PR #2102 ("fix(extractors): extract bare super(...) constructor calls as call edges", merged 2026-07-17) touches extractor logic and directly involves constructor-call edges — plausible mechanism for the C# constructor-role divergence above. However, main's own official push-triggered CI run for that exact commit (2e0e94fa) passed Engine parity cleanly on all 3 platforms, while multiple PR-triggered runs against the same or near-identical commit fail consistently. That discrepancy (push-run passes, PR-runs fail) is itself worth investigating — possibly a pull_request vs push event/matrix/concurrency difference, test ordering sensitivity, or environment/caching difference between trigger types — rather than assuming the extractor change itself is deterministic-safe.

Bug 2: Native addon crash on CLI -f array arguments

A separate, also deterministically-reproducing failure:

codegraph: fatal error — Failed to convert JavaScript value Object ["math.js"] into rust type String

Confirmed identical on multiple independent PR runs. Affects:

• tests/cli.test.ts (-f scoping tests)
• tests/integration/incremental-parity.test.ts
• Multiple regression tests: issue-1730, issue-1734, issue-1738, issue-1742, issue-1753, issue-1769

This looks like a native (napi-rs) binding issue marshaling an array argument (-f/file-filter) as a single string, rejecting an array/object where a Rust String is expected.

Evidence this is deterministic, not flaky

Reproduced with the identical failure signature (same test names, same fixtures, same counts) across at least 5 separate CI runs triggered by completely unrelated PRs:

• build(deps-dev): bump tree-sitter-gleam from c610c28 to cefbd68 #2126 (tree-sitter-gleam devDependency bump)
• build(deps): bump actions/setup-node from 6 to 7 #2119 (actions/setup-node GitHub Actions bump)
• build(deps): bump web-tree-sitter from 0.26.10 to 0.26.11 #2124 (web-tree-sitter devDependency bump)
• build(deps-dev): bump commit-and-tag-version from 12.7.3 to 13.0.0 #2123 (commit-and-tag-version devDependency bump)
• fix(bench): apply KNOWN_REGRESSIONS baseline fallback to release publish gate, not just dev #2129 (a benchmark-test-only change, still showed Engine parity (macos-latest) failing on a fresh commit)

None of these PRs touch extraction, parsing, or native-binding code, so their diffs cannot be the cause.

Impact

Every open PR in this repo currently shows red CI on Test Node 22 and Engine parity regardless of content, which:

• Makes CI red the default/expected state, eroding its value as a merge gate
• Blocks the dual-engine parity guarantee this project's architecture depends on
• Forces every PR author/reviewer to manually distinguish "real failure" from "known noise"

Suggested next steps

1. Bisect between the last known-good push-triggered main run and the first PR run showing this signature to find the actual introducing commit (candidate: fix(extractors): extract bare super(...) constructor calls as call edges #2102, but not confirmed).
2. Reproduce locally (not just in CI) to rule out CI-environment-specific causes (concurrency, caching, pull_request vs push trigger differences).
3. Fix the identified engine's incorrect output for Bug 1 (per project policy: fix the less-accurate engine, don't special-case the test).
4. Fix the napi-rs argument marshaling for Bug 2's -f flag handling.

[carlos-alm]

Update: root cause found, no source fix needed — this is fully resolved by #2128

I dug into this expecting to find two separate source-level bugs (a napi arg-marshaling bug and an extractor/role-classifier divergence). That was wrong. Both symptoms disappear completely with a freshly built native binary — there is no bug in crates/codegraph-core's extractors, role classifiers, or napi bindings on current main.

What's actually happening

1. v3.16.0 was tagged as part of a release attempt (commit 2e0e94fa), but that release failed at the Pre-publish benchmark gate before ever reaching the publish step (this is the bug PR fix(bench): apply KNOWN_REGRESSIONS baseline fallback to release publish gate, not just dev #2129 fixes) — so no v3.16.0 npm platform packages were ever published. The tag exists; the binaries don't.
2. .github/workflows/ci.yml's detect-changes job picks LAST_TAG as the newest semver git tag (v3.16.0) to decide whether native-host-build needs to run. Since v3.16.0's tag commit is current HEAD, git diff v3.16.0 HEAD -- crates/ Cargo.toml Cargo.lock src/infrastructure/native.ts is empty → native_changed=false → native-host-build (and the downstream ci-install-native.mjs step that overwrites the npm-published binary with a freshly built one) gets skipped.
3. Tests then run against whatever npm install pulled down: the last actually-published platform package, pinned at version 3.15.0. Diffing against v3.15.0 (not v3.16.0) shows 56 changed native-relevant files — so that published binary is 56 commits' worth of Rust/native-interface changes stale, including things like PR fix(extractors): extract bare super(...) constructor calls as call edges #2102's super(...) constructor-call-edge fix and earlier file-filter widenings (fix: prevent fn-impact/query crash when -f/--file is passed #1816, fix(native): widen NativeRepository file filters to accept string[] #1959).
4. Every test run compares this stale native binary against a freshly-built WASM engine (WASM grammars are always rebuilt from current source via npm install's prepare script) — hence the "parity divergence." It isn't engine drift, it's one engine running old code.
5. The same stale binary explains the CLI crash: current TS source calls the native fn_deps/findNodesByFile-family functions passing an array for -f, matching the current Rust signature (Option<Vec<String>>), but the stale 3.15.0-era binary underneath still expects a plain String, so napi's arg conversion fails with Failed to convert JavaScript value Object ["math.js"] into rust type String.

Empirical verification

In a clean worktree branched from origin/main (2e0e94fa):

• Built native fresh via napi build --release in crates/codegraph-core.
• Installed it over the published npm package exactly as scripts/ci-install-native.mjs does in CI.
• Re-ran the previously-failing suites:
  • tests/integration/cli.test.ts (the -f/--file scoping tests, incl. the exact crash repro): 5/5 pass.
  • tests/integration/build-parity.test.ts, tests/engines/ast-parity.test.ts, tests/engines/parity.test.ts: 73/73 pass (8 skipped, BENCH_CANARY-gated), including the C# produces identical edges/produces identical roles cases that were previously mismatched (77 vs 79 edges, core vs dead-ffi).

Zero failures once the native binary matches current source. No extractor, role-classifier, or napi-binding change was needed.

Conclusion

PR #2128 ("fix(ci): anchor native-change detection to package.json's version, not the latest tag") is the actual, complete fix for this issue — it makes detect-changes diff against the last published version instead of the last tagged one, so a dangling failed-release tag can no longer mask 56 files of native drift. Once #2128 merges, native-host-build will correctly run and ci-install-native.mjs will correctly install a current binary for every PR going forward, resolving both symptoms tracked here.

No separate source PR is needed for this issue. Closing this as resolved by #2128 — reopen if the failures reproduce again after #2128 merges.

[carlos-alm]

Closing — root cause is CI infrastructure (stale native binary from broken change-detection), not a source bug. Fully resolved by #2128 once merged; see investigation above.