fix(core): a timed-out receipt wait stops polling for later waits on the same tx hash

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

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, typescript
領域
backend-api-design

調査の方向性

Start with utils/wait-for-transaction-receipt.ts and the waitForSubmission callers named in the issue, then inspect the waitForDeletePieces tests referenced in #1095. Reproduce the retry scenario with one client and transaction hash, and compare the listed options, including viem’s observer cleanup behavior. Done when a timed-out or aborted first wait no longer prevents a later wait from receiving the receipt.

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

説明

Problem

viem's waitForTransactionReceipt shares one block poller per client.uid and transaction hash. When the first wait on a client and hash times out, it stops that shared poller, even while later waits on the same pair are still subscribed. Those later waits then never see the receipt and only end at their own timeout.

This affects core because waitForSubmission (behind waitForAddPieces, waitForCreateDataSet, waitForCreateDataSetAddPieces and waitForDeletePieces) wraps viem's wait in abortable. Aborting rejects our promise but leaves viem's wait running until its timeout. So if a caller aborts a wait and retries on the same client and hash, the aborted wait's timer later kills polling for the retry.

The null-round wrapper in utils/wait-for-transaction-receipt.ts copies client.uid, so it shares the same observer key.

In review of #1095, BravoNatalie measured a retry whose receipt was ready at 500 ms. It timed out after 3 s instead of resolving at about 520 ms.

Cause

In viem 2.55.19, _esm/actions/public/waitForTransactionReceipt.js:

const observerId = stringify(['waitForTransactionReceipt', client.uid, hash])
let _unwatch
const timer = timeout
  ? setTimeout(() => {
      _unwatch?.()   // stops the shared watchBlockNumber
      _unobserve?.()
      reject(new WaitForTransactionReceiptTimeoutError({ hash }))
    }, timeout)
  : undefined
_unobserve = observe(observerId, { onReplaced, resolve, reject }, async (emit) => {
  // ...
  _unwatch = getAction(client, watchBlockNumber, 'watchBlockNumber')({ ... })
})

observe runs the callback only for the first subscriber, so only the first wait's _unwatch points at the shared watchBlockNumber. That wait's timeout calls _unwatch() directly. This bypasses observe's unwatch, which runs cleanup only when the last listener leaves. The later listeners stay registered with nothing polling.

Options

  • Give each wait its own observer key, for example a unique uid on the client copy made in utils/wait-for-transaction-receipt.ts. This trades the shared poll for independent waits.
  • Stop viem's wait when our signal aborts, so an aborted wait can't outlive the caller. That needs an abortable viem call or our own polling loop.
  • Report it upstream to viem: the timeout should go through observe's unwatch rather than call _unwatch directly.

The waitForDeletePieces tests in #1095 use their own client to avoid this.

主要言語
TypeScript
スター
28
フォーク
35
平均マージ
2日 4時間
マージ済み PR（30日）
44

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

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

FilOzone/synapse-sdk のほかの issue

FilOzone/synapse-sdk の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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