Skip to content

Fix MultiPodBuilder external input accounting and scheduling - #540

Open
robknight wants to merge 4 commits into
mainfrom
fix_too_many_input_pods
Open

Fix MultiPodBuilder external input accounting and scheduling#540
robknight wants to merge 4 commits into
mainfrom
fix_too_many_input_pods

Conversation

@robknight

@robknight robknight commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

Correct several related issues in how MultiPodBuilder accounts for and schedules external inputs.

  • Count every generated POD’s predecessor as an input POD, even when no statements are imported from it.
  • Preserve concrete external POD identity instead of identifying PODs by their public-statement hash.
  • Avoid counting external opening statements twice against the statement limit.
  • Add an external-opening-first candidate ordering so the first POD can use its available external input slots and carry those statements forward through the chain.

Both the heuristic and MILP partitioners now use consistent input-POD and statement accounting. Diagnostics report total input-POD usage, and materialization asserts that its concrete input list agrees with the solver.

Every generated POD after the first installs its predecessor in input slot 0, even when it imports no statements from that POD. Charge this slot in both partitioners, report total input-POD usage in diagnostics, and verify that materialization agrees with the solver.
Track external dependencies by builder input position instead of public-statement hash. Distinct input PODs can expose the same statement tree, so hash-based coalescing can undercount input slots and attach the wrong concrete POD during materialization.
External imports are already represented by assigned Open or synthetic nodes, which consume their statement-table slots. Only cross-POD chain imports create additional statements, so remove the duplicate external-import charge from the heuristic, MILP model, and diagnostics.
Add an external-opening-first topological ordering candidate so POD 0 can use its external input slots before later PODs reserve one for their predecessor. Mark frontend Open operations and synthetic republishes in the symbolic costs, retain the existing candidates, and cover a plan that drops from three PODs to two.
@robknight
robknight force-pushed the fix_too_many_input_pods branch from 77b1be6 to 25f086f Compare August 27, 2026 14:16
@robknight robknight changed the title Fix bug where too many input PODs can be specified Fix MultiPodBuilder external input accounting and scheduling Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant