Skip to content

Prototype NDStateMachine final-state reconciliation - #525

Draft
nikhilsrikrishna wants to merge 2 commits into
CiscoDevNet:developfrom
nikhilsrikrishna:draft/issue-389-state-reconciliation
Draft

Prototype NDStateMachine final-state reconciliation#525
nikhilsrikrishna wants to merge 2 commits into
CiscoDevNet:developfrom
nikhilsrikrishna:draft/issue-389-state-reconciliation

Conversation

@nikhilsrikrishna

Copy link
Copy Markdown
Collaborator

Purpose

Addresses #389.

This draft PR demonstrates one possible shared approach for making
NDStateMachine report changed and after from controller mutation
outcomes 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

  • Separate immutable before, prospective planned, response-backed
    confirmed, and optional readback observed state.
  • Build the mutation plan without changing confirmed controller state.
  • Record controller request attempts before sending them so response-loss and
    timeout paths remain visible.
  • Record the result of each logical create, update, or delete operation before
    returning or raising an error.
  • Apply only proven successful effects to confirmed.
  • Calculate changed from mutation evidence independently of after.
  • Omit after and diff when an executed mutation leaves the final state
    unknown instead of returning the complete plan as controller state.
  • Provide an opt-in final-state readback path for unknown outcomes at the outer
    finalization boundary.
  • Add cache invalidation hooks so a verification read does not reuse the
    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

  • Focused reconciliation tests: 57 passed.
  • Complete unit suite: 4,089 passed.
  • Coverage includes sequential success/failure, partial Multi-Status results,
    uncertain delivery, check mode, confirmed changed, optional readback, cache
    invalidation, and mutation-free planning.

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