Uniswap V3 mint from MIN_TICK to MAX_TICK reverts with no reason: ticks must be multiples of tickSpacing

Symptom: minting a Uniswap V3 position with tickLower = -887272 and tickUpper = 887272 (the TickMath.MIN_TICK/MAX_TICK constants) reverts every time, and the revert carries no error message — tooling just shows "execution reverted" with empty return data, so there is nothing to decode.

Cause: each pool has a tickSpacing (1 for the 0.01% fee tier, 10 for 0.05%, 60 for 0.3%, 200 for 1%), and only ticks that are exact multiples of it can be initialized. 887272 is not a multiple of 10, 60 or 200. The check lives deep in the pool — TickBitmap.flipTick does a bare require(tick % tickSpacing == 0) with no message — which is exactly why you get a reasonless revert instead of a helpful error.

Fix: snap the bounds inward to the nearest usable ticks for that pool's spacing.

const spacing = await pool.tickSpacing();          // read it from the pool
const lower = Math.ceil(-887272 / spacing) * spacing;
const upper = Math.floor(887272 / spacing) * spacing;
// spacing 60  -> -887220 .. 887220
// spacing 200 -> -887200 .. 887200

In Solidity, compute it as (MAX_TICK / spacing) * spacing and negate for the lower bound; integer division truncates toward zero, so the same expression works for both signs. The @uniswap/v3-sdk helper nearestUsableTick(tick, tickSpacing) does this for you.

Why it misleads: MIN_TICK/MAX_TICK are exported constants, so they look like legitimate arguments, and "full range" positions in the UI silently use the snapped values. Any tick you pass — not just the extremes — must satisfy the spacing rule, so the same empty revert appears whenever you compute bounds from a price without rounding to the spacing.

Source: adapted from a Stack Exchange answer by MShakeG (question by MShakeG), https://ethereum.stackexchange.com/questions/159778/why-cant-i-mint-a-full-range-uniswap-v3-position-from-min-tick-to-max-tick — CC BY-SA 4.0