workflow update

Update workflow definitions, manage versions, and handle migrations.

Overview

The hyperfold workflow update command modifies workflow definitions with automatic versioning. Updates can be deployed incrementally, with full rollback support and migration tools for in-progress executions.

Workflow updates create new versions automatically. Running executions complete on their original version unless explicitly migrated.

Usage

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Update a workflow definition
$ hyperfold workflow update order-fulfillment \
--file=workflows/order-fulfillment.yaml
Validating workflow definition...
✓ Syntax valid
✓ All referenced agents exist
✓ Step dependencies resolved
Changes detected:
+ Added step: fraud_check (between validate_order and reserve_inventory)
~ Modified step: notify_customer (added SMS channel)
- Removed step: legacy_sync
Deploy update? [Y/n] y
Deploying workflow update...
✓ New version created: v3
✓ Triggers updated
✓ Running executions will complete on v2
WORKFLOW UPDATED
Workflow: order-fulfillment
Previous Version: v2
Current Version: v3
Status: active

Updating Individual Steps

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Update a single workflow step
$ hyperfold workflow update order-fulfillment \
--step=notify_customer \
--config='{
"channels": ["email", "sms"],
"templates": {
"email": "order-confirmation-v2",
"sms": "order-shipped"
}
}'
Step updated:
Workflow: order-fulfillment
Step: notify_customer
Changes: Added SMS channel
# Update step timeout
$ hyperfold workflow update order-fulfillment \
--step=create_shipment \
--timeout=60s \
--retries=3
# Update step agent
$ hyperfold workflow update order-fulfillment \
--step=validate_order \
--agent=order-validator-v2

Configuration Updates

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Update workflow-level configuration
$ hyperfold workflow update order-fulfillment \
--timeout=120s \
--retry-policy='{
"max_retries": 3,
"backoff": "exponential",
"initial_delay": "1s",
"max_delay": "30s"
}'
# Update error handling
$ hyperfold workflow update order-fulfillment \
--on-failure='{
"action": "notify",
"channels": ["slack:#ops-alerts", "pagerduty"],
"include_context": true
}'
# Update concurrency limits
$ hyperfold workflow update order-fulfillment \
--max-concurrent=100 \
--queue-strategy=fifo
# Pause workflow
$ hyperfold workflow update order-fulfillment --pause
Workflow paused:
New triggers queued (not executed)
In-progress executions continue
# Resume workflow
$ hyperfold workflow update order-fulfillment --resume
Workflow resumed:
Processing 45 queued triggers...

Version Management

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# List workflow versions
$ hyperfold workflow versions order-fulfillment
WORKFLOW VERSIONS: order-fulfillment
VERSION STATUS CREATED EXECUTIONS ACTIVE RUNS
v3 active 2025-01-20T10:00Z 0 0
v2 archived 2025-01-15T10:00Z 4,521 3
v1 archived 2025-01-01T10:00Z 12,456 0
# Show version diff
$ hyperfold workflow diff order-fulfillment --from=v2 --to=v3
WORKFLOW DIFF: order-fulfillment (v2 → v3)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STEPS
+ fraud_check [NEW]
├─ Agent: fraud-detector
├─ Timeout: 10s
└─ After: validate_order
~ notify_customer [MODIFIED]
├─ channels: ["email"] → ["email", "sms"]
└─ template: v1 → v2
- legacy_sync [REMOVED]
CONFIG
~ retry_policy: 2 → 3
~ timeout: 30s → 45s
# View specific version
$ hyperfold workflow show order-fulfillment --version=v2

Version Retention

StatusDescriptionRetention
activeCurrent version for new executionsIndefinite
archivedPrevious versions with execution history90 days
deprecatedMarked for removal, no new executions30 days

Rollback

Quickly revert to a previous workflow version:

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# Rollback to previous version
$ hyperfold workflow rollback order-fulfillment
Available versions:
v3 (current) - 2025-01-20T10:00Z
v2 - 2025-01-15T10:00Z
v1 - 2025-01-01T10:00Z
Rollback to which version? v2
Rolling back order-fulfillment to v2...
⚠ Warning: 3 executions in progress on v3
These will complete on v3 before rollback takes effect.
Confirm rollback? [y/N] y
✓ Workflow rolled back to v2
New triggers will use v2
In-progress v3 executions: 3 (completing)
# Force rollback (cancel in-progress)
$ hyperfold workflow rollback order-fulfillment --to=v2 --force
⚠ This will cancel 3 in-progress executions
Confirm force rollback? [y/N] y
✓ 3 executions cancelled
✓ Workflow rolled back to v2
# Rollback with reason (for audit log)
$ hyperfold workflow rollback order-fulfillment \
--to=v2 \
--reason="Bug in fraud_check step causing false positives"

Migration

Migrate in-progress executions to a new version:

bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Migrate running executions to new version
$ hyperfold workflow migrate order-fulfillment \
--from=v2 \
--to=v3
Analyzing migrations...
MIGRATION PLAN
Executions to migrate: 3
Compatible steps: 4/5
Requires intervention: 1
STEP COMPATIBILITY
✓ validate_order Compatible
✓ reserve_inventory Compatible
? fraud_check New step (will be skipped for in-progress)
✓ create_shipment Compatible
✓ notify_customer Compatible (config merged)
Proceed with migration? [y/N] y
Migrating executions...
exec_789 at step 3/5 → migrated to v3
exec_790 at step 2/5 → migrated to v3
exec_791 at step 4/5 → migrated to v3
✓ 3 executions migrated to v3
# Dry-run migration
$ hyperfold workflow migrate order-fulfillment --from=v2 --to=v3 --dry-run
DRY RUN - No changes will be made
Would migrate:
exec_789: step 3 → v3 step 4 (skip fraud_check)
exec_790: step 2 → v3 step 3 (skip fraud_check)
exec_791: step 4 → v3 step 5 (direct mapping)

Migration Strategies

Skip New Steps

New steps added in the target version are skipped for migrated executions. Use when new steps are enhancements, not requirements.

Backfill

Execute new steps retroactively before continuing. Use when new steps produce data required by subsequent steps.

Complete on Original

Let in-progress executions finish on their original version. Simplest approach when backwards compatibility isn't required.

Always use --dry-run before migrating production executions to verify compatibility.
Monitor workflow execution with Observability and Chain of Thought Logs.