[QmZsgJLiLQKpb8hxTmQ5LWyrFVvfWzVaL4WK8dfFBn7EeK] `handleInitialize` drops the Pool when a currency's `decimals()` reverts

[0x19dG87]

Repo: Uniswap/v4-subgraph
Deployment seen on: QmZsgJLiLQKpb8hxTmQ5LWyrFVvfWzVaL4WK8dfFBn7EeK (V4, Ethereum mainnet)

Problem

If a pool is initialized with a token whose decimals() reverts, handleInitializeHelper returns
early and never saves the Pool entity. The Initialize event is lost permanently, so the pool
and all of its swaps are missing from the subgraph.

src/mappings/poolManager.ts#L78-L84:

const decimals = fetchTokenDecimals(event.params.currency0, tokenOverrides, nativeTokenDetails)

// bail if we couldn't figure out the decimals
if (decimals === null) {
  log.debug('mybug the decimal on token 0 was null', [])
  return
}

Same for currency1 at #L105-L110
(note: that branch logs "token 0" too, which is misleading).

fetchTokenDecimals
returns null whenever try_decimals() reverts. By contrast,
fetchTokenSymbol
and fetchTokenName
already fall back to 'unknown'. Decimals is the only metadata call that aborts indexing instead of
degrading gracefully.

Real occurrence

Block	25709273
Tx	0x812855aba2c3764d3df74f90e9549e543a75ae6735a8f2f0a7a52b1c31f81114
Pool id	0xc8a28c2bcce2f26a172a85ac5162d5240d26970d95494c446b27bf1b8e982e45
currency0	0x0000000000000000000000000000000000000000 (native)
currency1	0xf1d2d880c5dde7cc912636c2b4d080b3fe5f7b50

currency1 reverts on the whole ERC-20 metadata surface (it is a deployed contract, just not a
standard ERC-20):

$ cast call 0xf1d2d880c5dde7cc912636c2b4d080b3fe5f7b50 "decimals()" --block 25709273
Error: execution reverted

Initialize (logIndex 208) and the pool's first Swap (logIndex 211) are in the same
transaction, so the pool breaks immediately. Result in the store: no Pool row, no Token row,
no swaps - the pool simply does not exist.

Two different symptoms

The current main already guards the load in
src/mappings/swap.ts#L163-L168:

const pool = Pool.load(poolId)

if (!pool) {
  log.warning('Pool not found: {}', [poolId])
  return
}

So depending on the build:

• Older builds (like the deployment above, which non-null-asserts the pool) abort the handler:

  Mapping aborted at src/mappings/swap.ts, line 39, column 16, with message: unexpected null
  

  With nonFatalErrors enabled the subgraph is then stuck unhealthy forever. The error is
  deterministic, so it hits every indexer and cannot be repaired by rewinding or resyncing.

• Current main logs a warning and returns - no error, but the pool's swaps, volume and TVL are
  silently missing from all aggregates. Arguably worse, since nothing surfaces the gap.

Either way the underlying cause is the same: the Pool was never created.

Impact

• Pools with any non-standard-decimals() currency are entirely absent from the subgraph.
• Their swaps never contribute to PoolDayData / TokenDayData / UniswapDayData.
• Not fixable operationally - only a mapping change and redeploy helps.

[0x19dG87]

Same error for subgraph Qmd78a3BJf4TzD3H3QPQpBgUrzWZErSmJtFrsvUW6c3M6u