Repository navigation
Conversation
Each operation keeps its highest counter until a Workflow Task scheduled event carries it, and newer progress folds into a scheduled task that has not started, so a burst costs one task and writes no event of its own. A passive cluster forwards progress to the active one.
SDKs replay a heartbeat chain differently from live, so progress on one of its tasks could reach the Workflow in another activation. It now waits for the next normal task.
A retried heartbeat task is replayed within the same heartbeat chain, so the hold is persisted on the Workflow task info and released only when a task that is not a retry is scheduled.
Progress that folds into a scheduled task is newer than what that task's event carries, so the Workflow never saw the highest counter. It now waits for the next task once that one starts.
A cluster rebuilt from replicated events never has the heartbeat hold marker, so a converted retry could carry progress. A test now pins that progress still reaches the Workflow around a rejected Update.
A long stream could fill the caller's History, one task per delivery. Progress that a task can't carry now waits instead of being dropped.
It ran on every transaction close and resolved the CHASM root each time.
moetemp
marked this pull request as draft
October 12, 2026 06:59
This was referenced Oct 14, 2026
Owner
Author
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
1 participant
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.
What changed?
This PR delivers Nexus operation progress to a CHASM caller Workflow on its next Workflow Task scheduled event, with no event of its own.
nexusoperation.progressMinInterval(1 s by default). Sooner progress folds and waits for a timer.Why?
Progress rides the scheduled event (DD-34), and a burst costs at most one extra task (DD-55). SDKs replay a heartbeat chain differently from live, so progress there could land in another activation (DD-52).
How did you test it?
Link to a test plan if any -
Functional
TestNexusOperationProgress*on both caller kinds,TestNexusProgressAcrossFailoverConversion, and the xdcTestNexusProgressForwardingSuite. The live lane covers it too.