foundry: Failed to deserialize response: expected value at line 1 column 1
Component
Forge
Have you ensured that all of these are up to date?
- Foundry
- Foundryup
What version of Foundry are you on?
forge 0.2.0 (8307d6d 2023-04-20T00:05:51.425008000Z)
What command(s) is the bug in?
forge verify-contract
Operating System
Linux
Describe the bug
I am running forge in an AWS EC2 instance and on verification keep getting a 403 error from Etherscan which results in the Failed to deserialize response: expected value at line 1 column 1 error as it returns html with a captcha rather than json.
I’ve reached out to Etherscan and this was their response:
We are aware of our CloudFlare protections being particularly sensitive to unknown automated scripts, and returning 403 responses as a result. We’re looking into whitelisting this at the moment, however a quick workaround for this would be to make your request more identifiable by attaching a User Agent string
My understanding is that reqwest doesn’t set a default User-Agent header and so CloudFlare decides to block my request.
Does anyone know of a way to add a User-Agent header to outgoing requests on forge?
This seems like it currently affects just a small subset of users, although it would future proof everyone if a default user agent was set by forge/foundry. For example, curl automatically applies a default user agent so it would make sense for forge/foundry to do the same.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 1
- Comments: 30 (6 by maintainers)
Commits related to this issue
- fix `forge verify-contract` etherscan cloudflare bug Etherscan verification for non-mainnet chains requires a question mark at the end of the verifier url in order to prevent a forward slash from bei... — committed to tsite/foundry by tsite 8 months ago
- fix(forge): fix `verify-contract` etherscan cloudflare bug (#6079) * fix `forge verify-contract` etherscan cloudflare bug Etherscan verification for non-mainnet chains requires a question mark at... — committed to foundry-rs/foundry by tsite 8 months ago
@Evalir yeah totally understood. It seems like the user agent string has not worked and I suspect this has to do with Cloudflare blocking the AWS IP range or something to that extent. The issue still persists with the latest build.
Definitely hard to test locally 😂
Is the foundry cloud build on ubuntu working with verification? Can’t remember if contract verification to etherscan is tested in the github action off the top of my head.
Hey @ratankaliani — we have a fix for contract verification on ethers-rs, we just need to upstream. It’ll be done in the upcoming days
Yeah I agree, would be good to add to these tests or a similar nightly suite to detect when there are Cloudflare errors.
I can confirm this issue does not exist for mainnet eth, only testnets it seems. Not sure there is much we can do but we should keep this open until the Etherscan team gives an update.
Issue has resolved for me - I was able to deploy & verify contracts on Optimism Goerli earlier today.
Looks like it’s broken on Gnosis as well - @mpeyfuss did you find a fix for Arbitrum Goerli?
Latest comms from the Etherscan API team made it seem like this is an issue they are aware of and their suggested User Agent fix doesn’t quite work from my testing. No response back about that. Seems to also be affecting Aribtrum Goerli (which uses etherscan).
I have yet to try on mainnet fully but my initial testing went a lot better on mainnet so it seems restricted to goerli at least.
Ah, unfortunately still getting the same response even with the latest build.
ah thanks for pointing me to that. I was on an older build but just now built again from source on the EC2. about to test
Not 100% sure the kind of error returned as it doesn’t seem like a regular 403 error. But here is the html body that foundry couldn’t deserialize.