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

[official-burak]

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.

[vercel]

@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 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

[promiseeuler]

While testing this fix locally on commit 64f024ad, I confirmed that the two new genesis-block cases exercise both index: 0 and a non-zero index, so the regression is isolated to the falsy blockNumber: 0n check. The same explicit !== undefined guard is applied consistently in query enablement and the query-function precondition.

Validation:

• vitest run packages/core/src/query/getTransaction.test.ts: 5 passed.
• biome check on both changed TypeScript files: clean.
• git show --check HEAD: passed.

I also ran the test from the main checkout as a control before noticing the worktree path: main collects only the original 3 cases, while this branch collects and passes all 5.