1.8 KiB
Software Review
Findings
High: required fields are defined, but no concrete message shape or example flow is provided
The event model is understandable, but two implementers could still serialize or correlate it differently. A non-normative example showing failure -> rollback-request -> rollback-result with task identifiers, dependency references, and partial-success handling would materially reduce ambiguity.
High: task state transitions are incomplete at the procedure level
The draft lists states but does not specify enough transition rules. For example, can a task move from completed directly to rollback-requested? Can compensation-required be terminal? Can rollback-failed later transition to rolled-back after manual intervention? Without a transition table or explicit rules, interoperability tests will be hard to design.
Medium: rollback scope remains too abstract for independent implementations
The draft requires a target checkpoint or explicit rollback set, but it does not describe the structure of a rollback set or how direct and transitive dependencies are represented. The draft needs at least a minimal abstract shape for scope membership.
Medium: timeout behavior is named but not operationalized
Timeout is listed as an error condition, but no rule says whether timeout yields failure, partial-success, or local retry. This will fragment behavior.
Open questions
- Is a compact transition table sufficient, or does the draft need a separate state machine subsection?
- Should rollback set representation be a list of task identifiers, checkpoint identifiers, or both?
Residual risk
The current draft is close to implementable, but it still needs one more layer of precision around flow shape and state progression before two vendors would likely build compatible behavior.