chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@bigmi/client@0.10.5

Patch Changes

• Updated dependencies [5b52eb3, 5b52eb3]:
  • @bigmi/core@0.9.3

@bigmi/core@0.9.3

Patch Changes

• #82 5b52eb3 Thanks @chybisov! - Keep the shared block watcher alive when a waitForTransaction times out. When a wait reached its retryCount timeout and the same block callback then found the transaction confirmed or replaced, or failed to fetch the block, its internal done ran a second time. That second pass ran the watcher's cleanup while another wait on the same client still listened, so that wait and every later wait on the client never settled. It could also settle a newer wait on the same txId with the stale error of the first one. done now runs at most once, and an observer's unwatch is a no-op once its own listener is gone.

  Release the observers of a settled waitForTransaction. A wait that joined another wait on the same txId, such as a resumed run, stayed in the module-level listenersCache with its callbacks after both settled, and a third wait on that txId joined it and never settled. Every finished wait also left an empty listenersCache key behind, one per txId. Each wait now removes its own listener when it settles. When the last listener leaves, observe drops the key and its cleanupCache entry and runs the cleanup, which removes the observer from the shared block watcher. A wait now joins another wait on the same txId only when both use the same confirmations, pollingInterval, retryCount, numeric retryDelay and senderAddress (a retryDelay function is not compared), so it no longer runs with the options of the wait it joined, such as resolving at 1 confirmation when it asked for 3.

  Make the timeout option of waitForTransaction end the wait. The timer only rejected the promise: it was never cleared and the block watcher kept polling, so a wait whose getblockcount never succeeded polled until the page or process ended. The timeout now rejects and removes only its own wait, so another wait on the same txId with a longer timeout or none keeps waiting, and the shared block watcher stops once no wait listens to it. Every way a wait settles clears its timer.

• #82 5b52eb3 Thanks @chybisov! - Stop waitForTransaction from reporting the awaited transaction as its own replacement. When getrawtransaction still reported the transaction unconfirmed but getblock already listed it, the replacement search matched the transaction itself, because it spends the same inputs, and called onReplaced with it. A replacement that getrawtransaction reported with no confirmations also resolved the wait at once, and a replacement that needed more confirmations resolved it in a later block without onReplaced. The search now skips the awaited txid, a replacement without confirmations keeps the wait polling, and onReplaced fires once, when the replacement has enough confirmations. It reports the awaited transaction as replacedTransaction and finds the reason against it, also when the replacement replaced an earlier replacement that left the chain.

  Settle withRetry when shouldRetry or the delay function throws. The throw rejected an internal attempt that nothing handled, so the returned promise stayed pending and the error surfaced only as an unhandled rejection. withRetry now rejects with that error. A retryDelay function of waitForTransaction that threw hung the wait in the same way; the wait now rejects with that error.

  Wait for every confirmation of a mined transaction in waitForTransaction. The retryCount block budget also counted the blocks after the transaction was mined, so a wait for more confirmations than the budget had left rejected with WaitForTransactionReceiptTimeoutError while the transaction was confirming: with the default retryCount of 10, a wait for 6 confirmations rejected if the transaction was mined 6 or more blocks after the wait started. The budget now counts only the blocks in which the transaction, or the replacement it tracks, is not mined or the height of its block is unknown. An unmined transaction still rejects on the same block as before.

  Evict the least recently used key from the internal LruMap that holds the in-flight requests of request deduplication. A key that was set again kept its old place, a read moved a key to the newest place only when its value was not undefined, an empty-string key was never evicted, and the eviction read the keys through the subclass, which viem reports can give a stale iterator on iOS 18 JavaScriptCore. A key that is set again or read now becomes the newest, the oldest key is evicted also when it is an empty string, and the eviction reads the keys of the base Map. This matters only when more than 8192 deduplicated requests are in flight at once.

@bigmi/react@0.9.5

Patch Changes

• Updated dependencies [5b52eb3, 5b52eb3]:
  • @bigmi/core@0.9.3
  • @bigmi/client@0.10.5