Problem/Motivation

When a workflow definition has a bug (a wrong node setting, a bad
notification type or template reference, and so on), fixing it only helps
new instances. A running instance stays pinned to the immutable
version snapshot it started on, so the only way to pick up the fix today is to
restart the process from the beginning. For long-running or partly-completed
processes that is painful and sometimes not acceptable.

Proposed resolution

Add the ability to migrate a running instance onto a newer workflow version.
Because each instance pins an immutable version snapshot by revision id,
migration is a re-point plus a compatibility check, not a state rewrite.

A service method, for example
migrateInstance(instance, target_version, node_map = []):

  • Collect the instance's live (parked and active) tokens and their node ids.
  • Compatibility check: every live token's node must exist in the target
    version, or be covered by node_map for a renamed node. Otherwise
    refuse and report the offending nodes.
  • Re-point the instance's definition version to the target, remapping token
    node ids when a map is given.
  • Audit-log the migration through the existing auditable event.

Expose it as a drush command, a per-instance operation in the UI ("Upgrade to
latest version"), and optionally a bulk action ("migrate all running instances
of workflow X to version N").

Remaining tasks / edge cases

  • Node id changes (renaming or removing a node a token currently sits on)
    require an explicit mapping; that is the one thing the migration cannot guess.
  • New required variables the target version reads should be pre-seedable as
    part of the migrate call.
  • Semantic changes to nodes a token has already passed are out of scope:
    migration only affects the not-yet-reached part of the graph, which is exactly
    the bug-fix sweet spot.

Issue fork orchestra-3607720

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mably created an issue. See original summary.

mably opened merge request !258

mably’s picture

mably commented
Status: Active » Needs review

The core "migrate a running instance to a newer version" capability already exists from #3604588 (the per-workflow bulk migrate, its version UI, and the drush orchestra:migrate-versions command). This issue is scoped to the per-instance follow-up.

MR !258 adds:

  • A per-instance migrateInstance() on the version manager, sharing the validate and apply logic with the bulk migrate().
  • An Operations column on the process instance list: Cancel, Migrate to current (running instances only, and only when behind the published version), and Delete; plus bulk Cancel selected and Migrate selected to current.
  • A cancel-before-delete rule enforced by an instance delete-access guard, with the list and confirm form aligned to it. Internal cascades and purges delete programmatically and are unaffected.

  • mably committed 1562da4e on 1.x 
    feat: #3607720 Migrate a running process instance to a newer workflow...
mably’s picture

mably commented
Status: Needs review » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.