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

Comienza en src/mappings/poolManager.ts, en handleInitializeHelper, y sigue fetchTokenDecimals en src/utils/token.ts, comparando su comportamiento con fetchTokenSymbol y fetchTokenName. Revisa la protección Pool.load en src/mappings/swap.ts y reproduce la ruta afectada de Initialize y Swap. Se considera terminado cuando una llamada a decimals() que hace revert ya no impide que Pool se almacene ni que sus swaps se procesen.

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

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.