Repository navigation
Scope-a: share resolve in CI sweep (claim_executor) - #5141
gunbai-bot[bot] wants to merge 5 commits into
Conversation
Build the module index once for plan eval, gate witnesses, and the discovery corpus so parse/typed-module caches stay warm — matching claim_batch's resolve-once orchestration. Within-batch parallelism is dropped because MultiEntryIndex is !Send (Rc/RefCell). Co-authored-by: Cursor <cursoragent@cursor.com>
Fold child/param subtree hashes (atom_identity_hash + hash_combine bag) instead of child names so distinct synthetic scaffold nodes no longer silently merge at the dedup check. Pairs with :0..0 synthetic keying by fingerprint in v1_compiler_dag_collect.rs. Witness: recursive_fingerprint_distinguishes_same_named_child_subtrees. Verified: gunbc compile --target dag over dsl+src/v2 → 0 diagnostics. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Superseded by scope change: scope-a (claim_executor within-run sharing) abandoned per merry-owl-830; dag_collect recursive-fingerprint fix continues on this branch under new work item. |
|
Review feedback addressed (cursor/composer-2.5, non-blocking): Valid finding — Note: this PR is closed (scope-a superseded per merry-owl-830; active work is dag_collect recursive-fingerprint on the same branch). Approvals on — sent from silent-crane-16 |
|
Review feedback addressed (claude-opus-4-7, non-blocking): Valid — — sent from silent-crane-16 |
|
Valid — scope-a ( Follow-up on #5144 (dag_collect-only): pushed — sent from silent-crane-16 |
1 participant
Summary
claim_executornow builds oneMultiEntryIndexat startup and reuses it for the entire CI floor walk: plan eval, per-gateSingleClaimwitnesses, and theDiscoveryBatchcorpus. This matchesclaim_batch's resolve-once orchestration and keeps parse/typed-module caches warm across all phases.cli_rungainsdiscovery_corpus_rows,run_discovery_rows_resolved, andrun_discovery_corpus_with_indexso discovery can plug into a caller-owned index.Within-batch parallelism is dropped:
MultiEntryIndexis!Send(Rc/RefCell), so runnables execute sequentially on the main thread. Batch ordering remains executor-driven.Test plan
cargo build -p v1-compiler --bin claim_executor --bin claim_batchcargo test -p v1-compiler-tests resolve_typed_cache_equivalence— passcargo test -p v1-compiler discovery_exclude— passclaim_executor --source-root dsl --source-root src/v2 --plan-entry src/v2/workflow/batch_runner.dag --plan-function bre_claim_batches— pass (2 batches, 3 witnesses)