bug: TransactionReceiptNotFoundError: Transaction receipt with hash

[qnxdev]

Is there an existing issue for this?

• I have searched the existing issues

Package Version

1.2.9

Current Behavior

TransactionReceiptNotFoundError: Transaction receipt with hash "0x6d90d7e90e50773d6462a287a7c17a8a73559aae2183ee97f42aad2a345d834b" could not be found. The Transaction may not be processed on a block yet. Version: viem@1.2.10 at getTransactionReceipt (getTransactionReceipt.js:33:1) at async Object.onBlockNumber (waitForTransactionReceipt.js:122:1)

waitForTransactionReceipt is supposed to wait for txn instead of throwin err right?

Expected Behavior

Wait and return txn data

Steps To Reproduce

This my piece of code

const tx = await client.waitForTransactionReceipt({ hash });

Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

No response

Anything else?

No response

[jxom]

This is typically due to using a Public RPC Provider or RPC Provider that has aggressive load balancing & caching. Can you try the same with Alchemy, Infura, QuickNode or Ankr?

[prometx11]

What is the suggested solution for dapps where you need to access rpcs in the frontend?
Anyone could abuse the private RPC key if shared on the frontend.

This issue seems less common with Ethersjs, any idea why?

[jxom]

RPC API keys are designed to be used in the browser. You should be using the RPC Provider’s API key whitelisting to properly secure your key against abuse.

[ZimM-LostPolygon]

For me, this is happening even on a reliable private RPC (QuickNode). Here's the network requests sequence I'm seeing:

1. eth_getTransactionByHash succeeds, returns the transaction data.
2. eth_getTransactionReceipt returns null.
3. eth_getBlockByNumber with the transaction's block number succeeds, returns list of transactions that includes the one being awaited.
4. eth_getTransactionReceipt is called again, returns null, at which point TransactionReceiptNotFoundError is thrown.

This sequence looks somewhat odd, but since this seems to happen on any RPC, I believe this should still be handled gracefully. The alternative is to just put a loop with a try..catch block, but that's exactly the thing the library should be handling.

[kyriediculous]

Can confirm this is not working as intended. Issue should be re-opened.

Expect the library to actually wait for transactions even if RPC implements aggressive load balancing (using Alchemy tho).

[jxom]

Please open a new issue with a minimal reproducible example.

[mqklin]

I have the same issue. Sometimes zkSync https://mainnet.era.zksync.io throws this error as well, despite I checked that nonce is bigger then it was before. But not sure if it's an issue for v2.

[aptum11]

Experiencing the same.

[jxom]

#1056 (comment)

[aptum11]

  const { writeContractAsync } = useWriteContract();
  const publicClient = usePublicClient();


        const minABI = [
          {
            constant: false,
            inputs: [
              {
                name: "_to",
                type: "address",
              },
              {
                name: "_value",
                type: "uint256",
              },
            ],
            name: "transfer",
            outputs: [
              {
                name: "",
                type: "bool",
              },
            ],
            payable: false,
            stateMutability: "nonpayable",
            type: "function",
          },
        ];
        const amountToSend = parseUnits(
          tokenInput,
          tokenDecimals
        );
        const hash = await writeContractAsync({
          abi: minABI,
          address: address1,
          functionName: "transfer",
          args: [address2, amountToSend],
        });
        await publicClient.waitForTransactionReceipt({
          hash,
        });

[seanbhart]

experiencing the same issue. any update on the timeline for a fix?

[jxom]

Locking issue as replying without a minimal reproducible example isn’t helpful for anyone.

Please open a new issue with a minimal reproducible example.