fix(platform): re-inline sub-rules on redeploy and rollback (silent corruption)#162
Merged
Conversation
A direct publish stores the *authored* (un-inlined) studio draft in its deployment row, and rows predating inlining have no sub-rule graph either. Redeploy and rollback-to-version then dispatched that stored snapshot verbatim: its SubRule steps referenced a graph that wasn't there, and studio->engine conversion drops a dangling reference silently (ConvertError::SubRuleNotFound is defined but never returned). The 'same version' redeployed or rolled back to therefore ran with its sub-rule logic missing, changing decisions with no error surfaced. Re-inline the snapshot at both dispatch points before rolling it out. Inlining is idempotent (an already-inlined graph is skipped via the sub_rules.contains_key guard), so it heals old/direct-publish rows and no-ops on already-inlined ones (governed releases). Redeploy inlines before creating the deployment row so a now-missing sub-rule fails fast without orphaning a Dispatched deployment; rollback maps an unassemblable snapshot to SetupDependencyMissing so it settles as RollbackFailed instead of looping.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Re-parented onto current
main(replaces #161, whose branch history conflicted after the stacked #158/#160 squash-merges). Single commit; identical change.The bug (silent data corruption)
A direct publish stores the authored (un-inlined) studio draft in its deployment row, and rows predating inlining have no sub-rule graph either. Redeploy and rollback-to-version then dispatched that stored snapshot verbatim: its
SubRulesteps referenced a graph that wasn't in the payload, andstudio→engineconversion drops a dangling sub-rule reference silently (ConvertError::SubRuleNotFoundis defined but never returned). So the "same version" redeployed or rolled back to ran with its sub-rule decision logic missing, with no error surfaced. The governed release path is unaffected (it inlines + freezes at request-creation time).The fix
Re-inline the snapshot at both dispatch points before rolling it out. Inlining is idempotent (an already-inlined graph is skipped via the
sub_rules.contains_keyguard), so it heals old/direct-publish rows and no-ops on already-inlined (governed) ones. Redeploy inlines before creating the deployment row (fail-fast on a missing sub-rule, no orphanedDispatchedrow); rollback maps an unassemblable snapshot toSetupDependencyMissingso it settlesRollbackFailedinstead of looping.Verified:
cargo check -p ordo-platformclean on top of current main (includes #158+#160).