openworkflowdev / openworkflowdev/openworkflow

Parent workflow remains parked when child workflow deadline expires

オープン
#714 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
TypeScript
スター
1.3k
フォーク
66
平均マージ
1日 1時間
マージ済み PR(30日)
69

説明

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

  1. Define a child workflow and a parent that calls step.runWorkflow(child, input, { timeout: "1h" }).
  2. Create the child run with deadlineAt: new Date(Date.now() + 1000) (1s).
  3. Wait 2s for the deadline to pass.
  4. Trigger a claimWorkflowRun tick.
  5. 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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

postgres/backend.ts の 484 行目付近と sqlite/backend.ts の 414 行目付近から始め、claimWorkflowRun、completeWorkflowRun、wakeParentWorkflowRun を追ってください。child が期限切れになる parent のケースをカバーするテストを追加し、1 回のポーリングサイクル以内に parent が利用可能になることを検証してください。Postgres と SQLite の統合テスト、および既存の child-workflow テストの両方がパスする必要があります。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
postgresql, sqlite, typescript
領域
backend, databases, testing
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
明確に書かれている
初心者へのやさしさ
68/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。