Skip to content

[Fusion] Evaluate the include flags of a conditional incremental plan once - #160

Open
michaelstaib wants to merge 3 commits into
mst/fusion-skipped-deferred-groupfrom
mst/fusion-include-flags-once
Open

michaelstaib wants to merge 3 commits into
mst/fusion-skipped-deferred-groupfrom
mst/fusion-include-flags-once

Conversation

@michaelstaib

Copy link
Copy Markdown
Owner

The gateway evaluated the include flags of a conditional incremental plan twice per request. FindExcludedIncrementalPlans evaluated them to check whether the plan's groups are all excluded, and OperationPlanContext.Initialize evaluated them again when the plan started.

Changes:

  • The flags from the exclusion check are kept next to the plan's resolved delivery groups, in the per-request map the executor already builds. They are passed to OperationPlanContext.Initialize, which evaluates them only when none are given.
  • Initialize takes the flags as a required parameter, and every call site passes them explicitly.

No new allocation: the map already exists and the flags are stored inline. Requests without conditional incremental plans are unchanged. No OperationPlanner.Version bump, no plan JSON change, no snapshot changes.

Stacked on #150.

Tests: Fusion.Execution.Tests and Fusion.AspNetCore.Tests DeferTests on net10.0 and net8.0, unchanged and green.

No benchmark was run.

Copilot AI balanced review requested due to automatic review settings November 1, 2026 17:02

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

No active review issues are reported for the change to reuse evaluated include flags in incremental plans.

No open issues 🎉

What changed in this PR

This PR removes duplicate include-condition evaluation for conditional incremental plans in the Fusion gateway, building on #150’s deferred-group exclusion handling.

Changes:

  • Stores evaluated include flags alongside resolved delivery groups and reuses them when incremental plans start.
  • Adds a required nullable flags parameter to context initialization, retaining evaluation when no flags are supplied.
  • Updates production and test call sites without changing plan versions, JSON formats, or snapshots.
File Description
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​OperationPlanContextRoutingTests.cs Passes explicit null flags in routing setup.
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​OperationPlanContextResetTests.cs Passes explicit null flags in reset setup.
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​OperationPlanContextPoolingTests.cs Updates the pooling fixture’s initialization call.
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​ExecutionNodeCompletionTests.cs Updates completion-test context initialization.
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​Clients/​SourceSchemaClientTestBase.cs Updates shared client-test context setup.
src/​HotChocolate/​Fusion/​test/​Fusion.Execution.Tests/​Execution/​Clients/​AliasBatching/​AliasBatchRequestSelectionTests.cs Updates alias-batching context setup.
src/​HotChocolate/​Fusion/​src/​Fusion.Execution/​Execution/​OperationPlanExecutor.cs Stores and forwards per-request include flags.
src/​HotChocolate/​Fusion/​src/​Fusion.Execution/​Execution/​OperationPlanContext.Pooling.cs Uses supplied flags or evaluates them when null.

Review effort: Balanced

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants