Repository navigation
task: remove the early resolution buffer - #135
Merged
Merged
Conversation
A completion, failure, timer firing or child result that reached the replay before the workflow had scheduled the matching step was buffered (dapr#125) and delivered once the step was scheduled. That made the Go SDK the only SDK that tolerated such an early resolution: Python, Java and JavaScript replay in order and ignore a resolution with no pending step, so the fix lived in one SDK while the cause, a backend that dispatches before it saves, stayed. dapr now hands the worker such a resolution after the events that lead the workflow to schedule the step, for new events and for histories already persisted in that shape (dapr/dapr#10590). The SDK goes back to ignoring an unmatched resolution, now with a warning, like the other SDKs. The applier change from dapr#133 stays: a scheduling whose resolution is already in the state is recorded but not dispatched. That is what keeps the step from running twice, and the backend relies on it. Signed-off-by: joshvanl <me@joshvanl.dev>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Task-kind validation and compatibility with persisted out-of-order histories remain unresolved.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Removes Go SDK early-resolution buffering, shifting event-ordering responsibility to the backend while preserving dispatch suppression.
Changes:
- Warn and ignore resolutions without pending steps.
- Replace buffering tests with ordering tests.
- Update applier comments without changing behavior.
| File | Description |
|---|---|
task/task.go |
Removes task-kind tracking and immediate callback handling. |
task/orchestrator.go |
Removes resolution buffers and adds unmatched-event warnings. |
task/orchestrator_buffered_test.go |
Deletes buffering tests and benchmark. |
task/early_resolution_test.go |
Adds ignored-versus-ordered resolution tests. |
backend/runtimestate/applier.go |
Updates comments; dispatch suppression remains unchanged. |
backend/runtimestate/applier_test.go |
Updates test comments only. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Signed-off-by: joshvanl <me@joshvanl.dev>
cicoyle
approved these changes
Oct 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A completion, failure, timer firing or child result that reached the replay before the workflow had scheduled the matching step was buffered (#125) and delivered once the step was scheduled. That made the Go SDK the only SDK that tolerated such an early resolution: Python, Java and JavaScript replay in order and ignore a resolution with no pending step, so the fix lived in one SDK while the cause, a backend that dispatches before it saves, stayed.
dapr now hands the worker such a resolution after the events that lead the workflow to schedule the step, for new events and for histories already persisted in that shape (dapr/dapr#10590). The SDK goes back to ignoring an unmatched resolution, now with a warning, like the other SDKs.
The applier change from #133 stays: a scheduling whose resolution is already in the state is recorded but not dispatched. That is what keeps the step from running twice, and the backend relies on it.