Stream write fails with HTTP 409 "inconsistent sequencing state" with concurrent writers (5.5.0, HTTP transport)

オープン
  • 何か問題がありますか？
#5,418 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
15/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
nodejs, typescript
領域
backend, distributed-systems

調査の方向性

The failure comes from the HTTP stream write path: a PUT to /api/v2/runs/<runId>/stream/<streamName> that returns 409 and is wrapped as a StreamError. Start there, then reproduce two concurrent getWritable() writers on the HTTP transport to see whether the conflict is reachable from client code. Done means either the concurrent-write conflict no longer occurs, or the 409 is classified as a non-retryable dropped write. The issue suggests the server side may be at fault, so this may end in a server change.

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

説明

Summary

On Vercel, a step that writes to a run's default stream intermittently fails with HTTP 409 and the server message Redis stream "strm_<runId>_user" has inconsistent sequencing state. The failure is deterministic once it starts: every retry of the step gets the same 409, so the step exhausts its retries and the run fails, even though the user-facing work in a parallel step had already succeeded.

Environment

  • workflow / @workflow/core / @workflow/world-vercel 5.5.0
  • Vercel world, Fluid compute, Node.js runtime
  • Streams pinned to the HTTP transport: WORKFLOW_STREAMS_TRANSPORT=http and WORKFLOW_EVENTS_TRANSPORT=http

What happens

  • Two steps of the same run write to the run's default stream at the same time: one writes model output chunks (getWritable() in a "use step" function, lock released in finally), the other writes small progress parts. The streaming docs say concurrent writers are allowed.
  • One write gets:
StreamError: Stream write failed: HTTP 409 (PUT https://vercel-workflow.com/api/v2/runs/<runId>/stream/strm_<runId>_user)
{"success":false,"error":"conflict","message":"Redis stream \"strm_<runId>_user\" has inconsistent sequencing state"}
  • Both writer steps then fail the same way on each retry (Max retries reached, bubbling error to parent workflow), and the run ends with FatalError / USER_ERROR wrapping the StreamError (STREAM_ERROR).
  • In our case the run was still executing on an older deployment while a newer one had been promoted; we have not confirmed whether that matters.

Expected

  • Concurrent writers to the same stream should not put the stream into an inconsistent state, or
  • if the state is unrecoverable, the error should be classified so callers can treat it as a dropped write rather than retrying an append that can never succeed.

Notes

  • On the HTTP transport the client sends no sequence or writer id, so the inconsistent state does not seem reachable from client behaviour; it looks server-side.
  • Possibly related: #4306 (acknowledged chunks missing under concurrent load), #5383 (stream socket closed mid-run on 5.4.0). Separately, #4414 means a step that catches this error still fails after its body returns, which turns a dropped progress write into a failed run.
  • Happy to provide run ids privately if useful.
主要言語
TypeScript
スター
2.5k
フォーク
401
平均マージ
2日 36分
マージ済み PR（30日）
150

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

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

vercel/workflow のほかの issue

vercel/workflow の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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