Skip to content

fix(native): stop scoping full-build dataflow-vertex extraction to files with edges - #2573

Merged
carlos-alm merged 2 commits into
mainfrom
fix/issue-2483
Aug 18, 2026
Merged

fix(native): stop scoping full-build dataflow-vertex extraction to files with edges#2573
carlos-alm merged 2 commits into
mainfrom
fix/issue-2483

Conversation

@carlos-alm

Copy link
Copy Markdown
Contributor

Summary

runDataflowVertexPass's full-build file selection (the P6 pass that backfills dataflow_vertices after the Rust orchestrator's edge-only dataflow pass) only included native-language files that already had dataflow EDGE rows (flows_to/returns/mutates) — on the theory that a file with no edges would produce zero vertices anyway.

That theory is wrong: a plain leaf function with params and a return but no calls to or from any other function has zero inter-procedural edges, yet still has vertex-worthy params/returns — extractDataflowAnalysis's vertex output isn't gated on argFlows/assignments/mutations being non-empty. In practice this meant the native engine silently dropped dataflow_vertices for most files in a typical codebase (confirmed empirically: bind-call-apply.js, class-scope.js, define-property.js, define-property-accessor.js in the javascript fixture, plus most of hierarchy.ts/index.ts/serializer.ts in typescript and several files in pts-javascript, all had zero native-engine vertices while WASM recorded them correctly), while WASM has always recorded vertices unconditionally.

Fix: the filter now includes any native-language file with at least one function/method definition (checked via the nodes table, kind IN CALLABLE_SYMBOL_KINDS) — which is what actually determines whether a file can produce vertices, not edge presence.

Verification

node scripts/parity-compare.mjs --dataflow across the full 34-language fixture suite:

The originally-filed issue's own note ("--dataflow requires migration v18 — worth checking whether the test DB has that migration applied") turned out not to be the cause — this was a genuine extraction-scoping bug, not a migration issue.

Test plan

  • New integration test tests/integration/issue-2483-native-dataflow-vertices-leaf-functions.test.ts — a real dual-function leaf-function fixture built end-to-end through buildGraph with the native engine, confirming both functions' param/return vertices are recorded
  • Revert-verified: disabling the new filter condition reproduces the pre-fix [] (zero vertices) for both new tests
  • Existing dataflow integration tests (dataflow-vertices, dataflow-p4-native, dataflow-incremental) still pass (28 passed)
  • npx tsc --noEmit -p ., npm run lint, full npm test (5487 passed)
  • Full parity-compare.mjs --dataflow run across all 34 language fixtures (42/42 OK on df-vertices)

Closes #2483

…les with edges

runDataflowVertexPass's full-build file selection only included
native-language files that already had dataflow EDGE rows
(flows_to/returns/mutates) from the Rust orchestrator, on the theory
that a file with no edges would produce zero vertices anyway. That
theory is wrong: a plain leaf function with params and a return but no
calls to or from any other function has zero inter-procedural edges
yet still has vertex-worthy params/returns -- extractDataflowAnalysis's
vertex output isn't gated on argFlows/assignments/mutations being
non-empty. In practice this meant the native engine silently dropped
dataflow_vertices for most files in a typical codebase, while WASM
recorded them unconditionally.

Confirmed via node scripts/parity-compare.mjs --dataflow: the full
34-language fixture suite goes from 1/42 fixtures OK on df-vertices
to 42/42 (the one remaining jelly-micro divergence is the pre-existing,
unrelated technique-label mismatch filed as #2572).

Fixes the filter to include any native-language file with at least
one function/method definition (via the nodes table), matching what
actually determines whether a file can produce vertices.

docs check acknowledged.

Closes #2483

Impact: 1 functions changed, 4 affected
@greptile-apps

greptile-apps Bot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR corrects native full-build dataflow-vertex selection by processing files containing callable definitions rather than requiring existing inter-procedural dataflow edges.

  • Adds callable-kind-based full-build filtering for native files.
  • Avoids unnecessary vertex extraction during empty incremental passes.
  • Adds native integration coverage for leaf-function vertices and no-op incremental preservation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
src/domain/graph/builder/stages/native-orchestrator.ts Broadens full-build vertex extraction to native files with callable definitions and explicitly skips empty incremental work.
tests/integration/issue-2483-native-dataflow-vertices-leaf-functions.test.ts Adds end-to-end native coverage for leaf-function vertices and their preservation across a no-op incremental rebuild.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Build["Native graph build"] --> Mode{"Full build?"}
  Mode -->|Yes| Query["Select files containing callable nodes"]
  Mode -->|No, changed files| Changed["Select changed files"]
  Mode -->|No changes| Skip["Skip vertex pass"]
  Query --> Extract["Extract native dataflow analysis"]
  Changed --> Extract
  Extract --> Persist["Persist parameter, return, and local vertices"]
Loading

Reviews (2): Last reviewed commit: "fix: skip dataflow-vertex full-build sca..." | Re-trigger Greptile

@github-actions

github-actions Bot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Codegraph Impact Analysis

2 functions changed5 callers affected across 4 files

  • runDataflowVertexPass in src/domain/graph/builder/stages/native-orchestrator.ts:323 (4 transitive callers)
  • tryNativeOrchestrator in src/domain/graph/builder/stages/native-orchestrator.ts:2829 (4 transitive callers)

…tal rebuild

Caught by CI's perf-canary: broadening runDataflowVertexPass's
full-build file filter (previous commit) also broadened how many files
a literal no-op incremental rebuild re-scans, since changedFiles=[]
fell into the same "full build" branch as changedFiles=undefined.

Adds the same "quiet incremental: nothing changed" early return
backfillEdgeTechniquesAfterNativeOrchestrator already has for the
identical isFullBuild=false, changedFiles=[] case, just above it in
the same file.

Verified locally: dataflow_vertices from a full build are still
present after a following no-op incremental rebuild (no data loss),
and a genuinely-changed file still gets its vertices re-extracted on
an incremental rebuild. The actual wall-clock regression this fixes
is measured by CI's own benchmark gate, which caught the original bug.

docs check acknowledged.

Impact: 2 functions changed, 5 affected
@carlos-alm

Copy link
Copy Markdown
Contributor Author

@greptileai

@carlos-alm
carlos-alm merged commit d132617 into main Aug 18, 2026
40 of 42 checks passed
@carlos-alm
carlos-alm deleted the fix/issue-2483 branch August 18, 2026 16:16
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 18, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(parity): native engine emits far fewer dataflow vertices than WASM for JS/TS/pts-javascript fixtures

1 participant