Current model
The new Flow model in #1 introduces an active-version pointer and draft, adopted, and archived states. The migration also stores active_flow_version_status on flows, alongside flow_versions.status.
This gives adoption a concrete place in the model. It would help to clarify how the pointer and statuses stay consistent, and what archiving means for requests and Sub-Flow references.
Behavior to clarify
Could adoption change the active version in one guarded operation that verifies the version belongs to the Flow and keeps the related statuses consistent? What role should active_flow_version_status play, and which field is authoritative if they disagree? If two adoption requests overlap, should one report a conflict instead of silently replacing the other's selection?
For serving behavior, could new requests use the newly applied version while existing executions receive a bounded period to finish on the previous one? Different serving instances may apply the change at different times, so the acceptable mixed-version period also needs a definition.
It would help to distinguish three possible meanings of ARCHIVED:
- No longer selected for new gateway requests.
- Unavailable for Sub-Flow calls, including references from other adopted Flows.
- Eligible for deletion once executions and dependent versions no longer need it.
When rollback is introduced, could it select an eligible previously published version? That action cannot by itself undo completed Flow steps, external effects, or incompatible data changes.
Tradeoffs
Guarding adoption prevents accidental overwrites, but competing deployments may fail and require a retry. Draining protects active requests while old and new versions compete for capacity. A longer drain period preserves more work and slows retirement; a short deadline can interrupt users.
What should make an old version eligible for retirement or rollback, and when may an execution be terminated?
Current model
The new Flow model in #1 introduces an active-version pointer and draft, adopted, and archived states. The migration also stores
active_flow_version_statusonflows, alongsideflow_versions.status.This gives adoption a concrete place in the model. It would help to clarify how the pointer and statuses stay consistent, and what archiving means for requests and Sub-Flow references.
Behavior to clarify
Could adoption change the active version in one guarded operation that verifies the version belongs to the Flow and keeps the related statuses consistent? What role should
active_flow_version_statusplay, and which field is authoritative if they disagree? If two adoption requests overlap, should one report a conflict instead of silently replacing the other's selection?For serving behavior, could new requests use the newly applied version while existing executions receive a bounded period to finish on the previous one? Different serving instances may apply the change at different times, so the acceptable mixed-version period also needs a definition.
It would help to distinguish three possible meanings of
ARCHIVED:When rollback is introduced, could it select an eligible previously published version? That action cannot by itself undo completed Flow steps, external effects, or incompatible data changes.
Tradeoffs
Guarding adoption prevents accidental overwrites, but competing deployments may fail and require a retry. Draining protects active requests while old and new versions compete for capacity. A longer drain period preserves more work and slows retirement; a short deadline can interrupt users.
What should make an old version eligible for retirement or rollback, and when may an execution be terminated?