State overrides can hide a real approval failure

State overrides answer a conditional question: would this call work if selected balances, storage or code were different? They do not establish that those conditions exist on chain.

Geth's eth_call extension accepts optional state and block overrides. That can help isolate a suspected allowance or balance problem without sending a transaction. Support is client-specific; do not assume every hosted RPC accepts the same extensions.

A useful diagnostic example

Suppose an ordinary preflight fails before the router can spend the input token. A controlled fork or correctly constructed override can model sufficient allowance and show whether later route execution also fails. If the hypothetical call succeeds, the result supports further investigation of authorization. It does not justify enabling Submit in the live interface.

Be careful about storage layout. Writing an assumed allowance slot can alter an unrelated field on a nonstandard or proxy token. Prefer a controlled fork transaction or a verified token implementation when you need to manipulate state for diagnosis.

Keep evidence labeled

Store a simulation mode field alongside every result: current state, fork with setup transactions, or overridden state. The user-facing ready-to-submit decision should require the mode your application explicitly supports. A green icon with no indication that the test invented a balance is misleading.

After the real approval succeeds, run an ordinary simulation of a fresh route. Remove diagnostic overrides from production request construction rather than relying on developers to remember a flag.

A regression fixture should deliberately produce an override-only success and verify that the application still blocks live execution. Another should use an RPC that rejects override parameters, proving that the failure is reported as unsupported simulation capability rather than a token problem.