Prototype NDStateMachine final-state reconciliation - #525
Draft
nikhilsrikrishna wants to merge 2 commits into
Draft
Prototype NDStateMachine final-state reconciliation#525nikhilsrikrishna wants to merge 2 commits into
nikhilsrikrishna wants to merge 2 commits into
Conversation
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.
Purpose
Addresses #389.
This draft PR demonstrates one possible shared approach for making
NDStateMachinereportchangedandafterfrom controller mutationoutcomes instead of from planned state.
It is intended to provide working code for discussion. It is not proposed as
a merge-ready implementation, and the internal types and output contract can
change based on review feedback.
Approach shown
before, prospectiveplanned, response-backedconfirmed, and optional readbackobservedstate.timeout paths remain visible.
returning or raising an error.
confirmed.changedfrom mutation evidence independently ofafter.afteranddiffwhen an executed mutation leaves the final stateunknown instead of returning the complete plan as controller state.
finalization boundary.
initialization snapshot.
Execution and verification behavior
This approach does not add a GET after every mutation. Known outcomes are
reconciled directly from their responses. A controller readback is considered
only when an outcome remains unknown and verification is enabled.
The existing module and orchestrator flow continues to decide request ordering
and whether execution stops after an error. This prototype does not introduce
a dependency graph, rollback, or a new continuation scheduler.
The public module argument wiring and the exact ownership of finalization are
left for discussion before this is converted into a merge-ready change.
Test notes
uncertain delivery, check mode, confirmed
changed, optional readback, cacheinvalidation, and mutation-free planning.