Skip to content

Preserve Flow-version consistency for in-flight executions #4

Description

@Geektrovert

Current model

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions