Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

workflow-runtime 0.0.3: sweep() never recovers a run whose worker died mid-step (fixed on main by #15, unreleased)

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

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

評価

難易度
1/5
見積もり時間
1時間未満
初心者へのやさしさ
15/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
github, node.js, typescript
領域
backend, release

調査の方向性

This asks for release PR #16 to publish core 0.0.5 and runtime 0.0.4; the fix is already merged in #15 and verified on main. Read #16 for the release status and project release instructions, then check whether the requested versions have shipped to npm. Done means both published packages include the fix so users can pin released versions.

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

説明

Versions

@tanstack/workflow-core 0.0.4, @tanstack/workflow-runtime 0.0.3 (latest on npm)

Describe the bug and the steps to reproduce it

If the process driving a run dies inside a step, the run stays running with an expired lease forever. In 0.0.3, runtime.sweep() only handles schedules and timers and never calls store.claimStaleRuns. Calling claimStaleRuns plus runWorkflow by hand doesn't help either, because core 0.0.4 has no recover mode, so replay stops at the last checkpoint.

#15 (merged 2026-07-21) fixes this: expired-run recovery in sweep(), recover: true in core, and lease heartbeats. I built main at b928717 and confirmed sweep() re-runs the interrupted step and finishes the run, and that the heartbeat stops a long step from being reclaimed mid-flight.

Request: could the release PR #16 be merged, so core 0.0.5 and runtime 0.0.4 ship to npm? That would let us pin a published version instead of a git SHA.

Your Minimal, Reproducible Example
import { createWorkflow } from '@tanstack/workflow-core'
import { defineWorkflowRuntime, inMemoryWorkflowExecutionStore } from '@tanstack/workflow-runtime'

const wf = createWorkflow({ id: 'wf', version: 'v1' }).handler(async (ctx) => {
  await ctx.step('a', async () => 1)
  return 'done'
})
const store = inMemoryWorkflowExecutionStore()
const runtime = defineWorkflowRuntime({ store, workflows: { wf: { load: async () => wf } }, defaultLeaseMs: 50 })

await store.createRun({ runId: 'r1', workflowId: 'wf', workflowVersion: 'v1', input: {}, now: Date.now() })
await store.claimRun({ runId: 'r1', leaseOwner: 'dead-worker', leaseMs: 50, now: Date.now() }) // worker dies here
await new Promise((r) => setTimeout(r, 100))

const sweep = await runtime.sweep()
console.log(sweep.summary, (await store.loadRun('r1'))?.status)
// 0.0.3: { scheduled: {}, timers: {}, eventCount: 0 } 'running'  (expected: recovered, then finished)
Do you intend to try to help solve this bug with your own PR?

No — the fix is already on main; this is a request to publish it.

Terms & Code of Conduct
  • I agree to follow this project's Code of Conduct
  • I understand that if my bug cannot be reliably reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
主要言語
TypeScript
スター
221
フォーク
10
PR マージ指標
30日以内にマージされた PR はありません

環境構築

はじめの一歩

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

TanStack/workflow のほかの issue

TanStack/workflow の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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