Skip to content

fix(core): enable getTransaction query for blockNumber 0 (genesis) - #5224

Open
official-burak wants to merge 1 commit into
wevm:mainfrom
official-burak:fix/get-transaction-block-number-zero
Open

fix(core): enable getTransaction query for blockNumber 0 (genesis)#5224
official-burak wants to merge 1 commit into
wevm:mainfrom
official-burak:fix/get-transaction-block-number-zero

Conversation

@official-burak

@official-burak official-burak commented Aug 19, 2026

Copy link
Copy Markdown

getTransactionQueryOptions tests blockNumber for truthiness in both the enabled guard and the queryFn precondition, so the genesis block 0n is treated as absent:

enabled: Boolean(
  (options.hash ||
    (options.index !== undefined &&
      (options.blockHash || options.blockNumber || options.blockTag))) &&
    (options.query?.enabled ?? true),
)

With { blockNumber: 0n, index: 0 } the inner group evaluates to undefined, so enabled is false and the query never fetches. The user cannot override it either, since query.enabled is ANDed with the same expression, so useTransaction({ blockNumber: 0n, index: 0 }) sits permanently idle with no error. If the queryFn is invoked directly it throws the misleading hash OR index AND blockHash, blockNumber, blockTag is required. Any other block number works, which masks the bug.

This is the remaining half of the same falsy check: #5197 corrected index on this exact expression but left blockNumber, and #5203 corrected blockNumber: 0n in getBalance / getTransactionCount for the same reason.

Nothing downstream blocks the value: viem's getTransaction accepts blockNumber: 0n, and filterQueryOptions uses rest destructuring so 0n is preserved in the query key.

Change

Compare blockNumber against undefined instead of testing truthiness, in both the enabled guard and the queryFn precondition, matching the treatment index already received. blockHash and blockTag are left as-is since they are non-empty strings when present.

Tests

Added two cases to packages/core/src/query/getTransaction.test.ts covering blockNumber: 0n with index: 0 and with a non-zero index, so the assertion isolates blockNumber rather than index.

Both fail on main and pass with this change:

# with the fix reverted
 × parameters: blockNumber 0 (genesis) with index 0 enables query
 × parameters: blockNumber 0 (genesis) with index enables query
 Tests  2 failed | 3 passed (5)

# with the fix
 Tests  5 passed (5)

The full packages/core/src/query suite passes: 54 files, 123 tests. biome check is clean on both changed files.

The `enabled` guard and the `queryFn` precondition in
`getTransactionQueryOptions` tested `blockNumber` for truthiness, so the
genesis block `0n` was treated as absent. `{ blockNumber: 0n, index }`
computed `enabled: false` and the query never fetched; forcing it to run
threw "hash OR index AND blockHash, blockNumber, blockTag is required".

This is the remaining half of the same falsy check corrected for `index`
in wevm#5197. viem's `getTransaction` accepts `blockNumber: 0n`, and
`filterQueryOptions` already preserves it in the query key.
@vercel

vercel Bot commented Aug 19, 2026

Copy link
Copy Markdown

@official-burak is attempting to deploy a commit to the Wevm Team on Vercel.

A member of the Team first needs to authorize it.

@changeset-bot

changeset-bot Bot commented Aug 19, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 64f024a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages
Name Type
@wagmi/core Patch
@wagmi/connectors Patch
wagmi Patch
@wagmi/solid Patch
@wagmi/vue Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant