Closed 3commascapital closed 3 months ago
Latest commit: 2f8ec7b9d8b15c1868b82d971138804c22ab614a
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
hardhat | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jul 9, 2024 10:09pm |
before this fix:
hardhat-verify found one or more errors during the verification process:
Etherscan:
Failed to send contract verification request.
Endpoint URL: https://api.scan.pulsechain.com/api?apikey=abc&module=contract&action=getsourcecode&address=0x...
The HTTP server response is not ok. Status code: 500 Response text: {"message":"Something went wrong.","result":null,"status":"0"}
after this fix:
Successfully submitted source code for contract
... at ...
for verification on the block explorer. Waiting for verification result...
Successfully verified contract ... on the block explorer.
https://...
I do not think that hardhat verify should cover all of the quirks of the many backends that are bound to emerge into eternity, however, I think that the force flag being more comprehensive (less narrowly applied) than it currently is could be a reasonable middle ground, provided that it does not run afoul of any eip's.
Agreed. I think this is a reasonable exception.
Thanks for the PR!
Looks great. Thank you!
Congrats, your important contribution to this open-source project has earned you a GitPOAP!
GitPOAP: 2024 Hardhat Contributor:
Head to gitpoap.io & connect your GitHub account to mint!
Learn more about GitPOAPs here.
There is a bug in blockscout's latest releases. It has been around for quite a while. Unfortunately it only happens in certain situations. The issue is that an
isVerified
check will fail if the backend is put into a certain state. The easy way around this would simply be to include that set of errors / states to be ignored when provided a force flag.I do not think that hardhat verify should cover all of the quirks of the many backends that are bound to emerge into eternity, however, I think that the force flag being more comprehensive (less narrowly applied) than it currently is could be a reasonable middle ground, provided that it does not run afoul of any eip's.