You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new Flow model in #1 provides an active_flow_version_id and explicit component versions on each step. An invocation can therefore resolve a Flow version at dispatch and follow that version's dependency graph.
For example, a checkout request could still be waiting for a payment HTTP response when a newer Flow version is adopted. If later steps read the active pointer again, the request could combine versions that were never validated together.
Behavior to clarify
Would it make sense for an invocation to capture its resolved Flow version at dispatch and retain that graph until it finishes, including the versions used by Sub-Flow calls?
There is a retention case beyond requests already running. An adopted checkout Flow may keep referencing Payment v1 after Payment v2 becomes active on its own gateway route:
flowchart LR
accTitle: A pinned Sub-Flow can outlive a change to its gateway route
accDescr: Checkout version 3 remains adopted and references Payment version 1. The payment gateway route now selects Payment version 2. New checkout requests can still need Payment version 1.
checkout["Checkout v3<br/>still adopted"] -->|pins| old["Payment v1"]
route["Payment gateway route"] -->|now selects| current["Payment v2"]
classDef default fill:#f6f8fa,stroke:#8c959f,color:#24292f;
Loading
New checkout requests would still need Payment v1, so waiting for existing executions to finish would not be enough to retire it. Could retention account for both active executions and references from other executable Flow versions?
Tradeoffs
Keeping those references stable makes an execution easier to explain and reproduce. Older versions also retain artifacts and may occupy runtime capacity, and a pinned dependency can continue running after a fix ships.
How long should superseded versions remain executable, and which events must override pinning? Permission revocation and an urgent dependency fix may need different treatment from an ordinary deployment.
Current model
The new Flow model in #1 provides an
active_flow_version_idand explicit component versions on each step. An invocation can therefore resolve a Flow version at dispatch and follow that version's dependency graph.For example, a checkout request could still be waiting for a payment HTTP response when a newer Flow version is adopted. If later steps read the active pointer again, the request could combine versions that were never validated together.
Behavior to clarify
Would it make sense for an invocation to capture its resolved Flow version at dispatch and retain that graph until it finishes, including the versions used by Sub-Flow calls?
There is a retention case beyond requests already running. An adopted checkout Flow may keep referencing Payment v1 after Payment v2 becomes active on its own gateway route:
flowchart LR accTitle: A pinned Sub-Flow can outlive a change to its gateway route accDescr: Checkout version 3 remains adopted and references Payment version 1. The payment gateway route now selects Payment version 2. New checkout requests can still need Payment version 1. checkout["Checkout v3<br/>still adopted"] -->|pins| old["Payment v1"] route["Payment gateway route"] -->|now selects| current["Payment v2"] classDef default fill:#f6f8fa,stroke:#8c959f,color:#24292f;New checkout requests would still need Payment v1, so waiting for existing executions to finish would not be enough to retire it. Could retention account for both active executions and references from other executable Flow versions?
Tradeoffs
Keeping those references stable makes an execution easier to explain and reproduce. Older versions also retain artifacts and may occupy runtime capacity, and a pinned dependency can continue running after a fix ships.
How long should superseded versions remain executable, and which events must override pinning? Permission revocation and an urgent dependency fix may need different treatment from an ordinary deployment.