duneanalytics / duneanalytics/evm.codes
chore: improve etherscan v2 DX (configurable chainid + explicit errors)
Open
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 827
- Forks
- 199
- Avg merge
- 15m
- Merged PRs (30d)
- 1
Description
Summary
Follow-up to the Etherscan V2 migration for Contract Viewer.
Problem
After switching from the deprecated V1 endpoint to V2, there are two developer-experience gaps:
chainidis hardcoded to mainnet (1), making non-mainnet usage harder.- parser errors collapse to a generic
etherscan response is not OK, which hides actionable upstream messages (e.g. invalid API key, unverified source, rate limits).
Proposal
- Make chain id configurable via env (e.g.
ETHERSCAN_CHAIN_ID, default1). - Preserve Etherscan
result/messagein thrown parser errors so users can diagnose quickly.
Context
- Related PR: #398
- Affected paths:
util/EtherscanApi.ts,util/EtherscanParser.ts
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading util/EtherscanApi.ts and util/EtherscanParser.ts, then trace how the Contract Viewer requests Etherscan V2 data and handles parser failures. Implement the configurable chain ID with a default of 1 and preserve Etherscan result/message details in thrown errors. Done means non-mainnet configuration works and upstream messages remain visible instead of only the generic error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, blockchain
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100