Background
When a child workflow run exceeds its deadlineAt, workers expire it to failed status inside claimWorkflowRun. The parent workflow parks itself waiting on the child via step.runWorkflow, which calls sleepWorkflowRun and releases the worker slot. The parent should be woken promptly when the child reaches a terminal state.
Problem
The deadline-expiry path in postgres/backend.ts:484 and sqlite/backend.ts:414 marks child runs as failed but never calls wakeParentWorkflowRun. The parent's availableAt is never updated to NOW(). The parent remains parked until its own availableAt — which is set to the runWorkflow timeout (default: 1 year from workflow start).
Steps to Reproduce
- Define a child workflow and a parent that calls step.runWorkflow(child, input, { timeout: "1h" }).
- Create the child run with deadlineAt: new Date(Date.now() + 1000) (1s).
- Wait 2s for the deadline to pass.
- Trigger a claimWorkflowRun tick.
- Observe: child is failed; parent availableAt remains 1 hour in the future.
Expected Behavior
When a child run is expired, the parent's availableAt is set to NOW() so it is picked up on the next poll cycle.
Proposed Solution
Postgres: Extend the expired CTE to also RETURNING "id", "parent_step_attempt_namespace_id", "parent_step_attempt_id". After the main claim UPDATE, run the same wake-parent UPDATE used by completeWorkflowRun against the expired IDs.
SQLite: After the expiry UPDATE, query the expired run IDs with RETURNING "id", "parent_step_attempt_id" and loop wakeParentWorkflowRun for each.
Acceptance Criteria
Integration test: parent wakes within one poll cycle after child deadline expires.
Both Postgres and SQLite backends pass the test.
No regression in existing child-workflow tests.
Background
When a child workflow run exceeds its deadlineAt, workers expire it to failed status inside claimWorkflowRun. The parent workflow parks itself waiting on the child via step.runWorkflow, which calls sleepWorkflowRun and releases the worker slot. The parent should be woken promptly when the child reaches a terminal state.
Problem
The deadline-expiry path in postgres/backend.ts:484 and sqlite/backend.ts:414 marks child runs as failed but never calls wakeParentWorkflowRun. The parent's availableAt is never updated to NOW(). The parent remains parked until its own availableAt — which is set to the runWorkflow timeout (default: 1 year from workflow start).
Steps to Reproduce
Expected Behavior
When a child run is expired, the parent's availableAt is set to NOW() so it is picked up on the next poll cycle.
Proposed Solution
Postgres: Extend the expired CTE to also RETURNING "id", "parent_step_attempt_namespace_id", "parent_step_attempt_id". After the main claim UPDATE, run the same wake-parent UPDATE used by completeWorkflowRun against the expired IDs.
SQLite: After the expiry UPDATE, query the expired run IDs with RETURNING "id", "parent_step_attempt_id" and loop wakeParentWorkflowRun for each.
Acceptance Criteria
Integration test: parent wakes within one poll cycle after child deadline expires.
Both Postgres and SQLite backends pass the test.
No regression in existing child-workflow tests.