Hardhat v3 returns "Internal error" instead of decoded revert reason for expired UniswapV2Router deadline

[catalina-uphold]

Version of Hardhat

3.2.0

What happened?

When calling swapETHForExactTokens on a UniswapV2Router contract with a deadline in the past, Hardhat v3 returns:

"message": "Internal error"

instead of the expected revert reason:

Error: VM Exception while processing transaction: reverted with reason string 'UniswapV2Router: EXPIRED'

This behavior differs from Hardhat v2, where the revert reason was correctly surfaced, like this Error: VM Exception while processing transaction: reverted with reason string 'UniswapV2Router: EXPIRED'.

Minimal reproduction steps

Steps:

1. Use Hardhat v3.2.0
2. Call swapETHForExactTokens on UniswapV2Router contract
3. Provide a deadline parameter that is already expired, e.g. 1700000000

Expected behavior:
Hardhat should decode and return the revert reason:
UniswapV2Router: EXPIRED

Actual behavior
Hardhat returns a generic error:

{
  "message": "Internal error",
  "txHash": "0xb9b4d2e93ffb6739fe1886e1c277d1bd6c15d59b88f66f9d6aaae134a806e851",
  "data": "0x08c379a000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000018556e69737761705632526f757465723a20455850495245440000000000000000"
}

Additional context
The data field contains the encoded revert reason:

0x08c379a000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000018556e69737761705632526f757465723a20455850495245440000000000000000

Decoding this yields:

UniswapV2Router: EXPIRED

This suggests that Hardhat v3 is not decoding the revert reason in this scenario, even though the information is available in the response data. This was working the expected way in hardhat v2.

Search terms

No response

[kanej]

Hey @catalina-uphold, is the code your working on open source? Or is it possible to point me at a reproducible example?

[catalina-uphold]

Our code is private, however the issue we have is very similar to this one #8043

Only the contract is different (see UniswapV2Router on Etherscan)

[catalina-uphold]

We simulated a similar transaction on ethereum testnet, if this helps: https://sepolia.etherscan.io/tx/0x52014604c7c14c4065527fdda518115115e4e9d68a7c0e9a314352eeb2a54ee6