feat(verify): preflight check verifier credentials before broadcasting#14777
Open
mablr wants to merge 19 commits into
Open
feat(verify): preflight check verifier credentials before broadcasting#14777mablr wants to merge 19 commits into
mablr wants to merge 19 commits into
Conversation
set on unsupported chain Co-authored-by: Amp <amp@ampcode.com>
zerosnacks
previously approved these changes
May 19, 2026
Contributor
zerosnacks
left a comment
There was a problem hiding this comment.
Nice! Simple fix but saves a lot of hassle
Oops - stale, found some things worth addressing
zerosnacks
reviewed
May 19, 2026
Contributor
zerosnacks
left a comment
There was a problem hiding this comment.
A few preflight-correctness concerns worth addressing before merge — focused on cases where this check could itself become the deploy-blocker it’s meant to prevent.
zerosnacks
reviewed
May 19, 2026
figtracer
reviewed
May 26, 2026
Validate verifier credentials before deployment so users get an early, actionable error instead of deploying and then having verification fail. Two layers of validation are now applied in `forge script` and `forge create` before any transaction is broadcasted: 1. Presence check (`VerificationProviderType::client`): fails immediately if required credentials are obviously absent. 2. Connectivity check (`VerifierArgs::check_credentials`): makes a lightweight network call to confirm credentials are actually accepted.
7a7182e to
c3b4ce5
Compare
Base automatically changed from
mablr/fallback_etherscan_unsupported_chain
to
master
May 28, 2026 12:45
- Demote BlockedByCloudflare, CloudFlareSecurityChallenge, RateLimitExceeded, and InvalidApiVersion from hard-fail to warn-and-proceed; transient CDN challenges and version mismatches must not block deploys - Split Custom verifier into its own branch using a raw HTTP probe with 401/403 detection, fixing the catch-all bypass for non-Etherscan-shaped auth error responses (figtracer) - Add HTTP status check to Sourcify custom-URL probe (warn on non-2xx/non-404) - Restore etherscan_api_key global config fallback in broadcast preflight, fixing regression for users with a top-level key in foundry.toml - Fix effective_type() -> resolve() in broadcast presence check so implicit Etherscan selection (key from env/config, no --verifier flag) is validated - Remove duplicate create_fails_early_on_bad_verifier_credentials test - Strengthen script preflight test to assert no broadcast occurred
Custom verifiers that return HTTP 200 with {"result":"Invalid API Key"}
were not caught by the credential check, which only inspected HTTP
status codes (401/403). Now also inspect the response body for the
invalid-API-key string so the preflight check correctly blocks
deployment.
Fixes create_preflight_fails_on_invalid_api_key and
script_fails_early_on_bad_verifier_credentials tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Validate verifier credentials before deployment so users get an early, actionable error instead of deploying and then having verification fail.
Two layers of validation are now applied in
forge scriptandforge createbefore any transaction is broadcasted:VerificationProviderType::client): fails immediately if required credentials are obviously absent.VerifierArgs::check_credentials): makes a lightweight network call to confirm credentials are actually accepted.Staked on top of #14765 (merge the current one after)
PR Checklist