feat: Complete unified ChainscanClient architecture implementation #37
Conversation
- Implement unified ChainscanClient.from_config() interface with 3 parameters - Add chain_registry.py for standardized chain ID mappings and aliases - Update all scanners (EtherscanV2, BlockScoutV1, MoralisV1, RoutScanV1) for chain_id support - Fix UrlBuilder integration with proper network parameter mapping - Update all tests, examples, and documentation to use new interface - Remove confusing aliases like 'main' and 'mainnet' from user-facing APIs - Maintain backward compatibility with existing Client interface - All tests pass, code follows quality standards (ruff, mypy)
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting
| # Resolve chain_id from network name/id | ||
| chain_id = resolve_chain_id(network) | ||
|
|
||
| # Get API key using existing config system | ||
| # For backward compatibility, map scanner names to their config IDs | ||
| scanner_id_map = { | ||
| 'blockscout': 'blockscout_eth', | ||
| 'etherscan': 'eth', | ||
| 'moralis': 'moralis', | ||
| 'routscan': 'routscan_mode', | ||
| } | ||
| scanner_id = scanner_id_map.get(scanner_name, scanner_name) | ||
| # Use the original network parameter for config lookup, not the resolved chain name | ||
| # Ensure network is a string for config lookup | ||
| network_str = str(network) if not isinstance(network, str) else network | ||
| client_config = global_config.create_client_config(scanner_id, network_str) |
There was a problem hiding this comment.
from_config
The new ChainscanClient.from_config resolves a chain_id but then forwards the raw network string to both ConfigurationManager.create_client_config and the scanner constructor. The configuration definitions still expose networks like 'main', 'goerli', 'mumbai', etc. (see config.py lines 104‑184 and validation at lines 432‑470), so passing the chain-oriented names or aliases shown in the docstring ('ethereum', 'eth', 'base', numeric IDs) causes a ValueError before the client can be created. As written, from_config('etherscan', 'v2', 'eth') or 'base' will fail even though the method is meant to be the canonical entry point. A mapping from chain aliases/IDs to the expected config network strings needs to happen before calling create_client_config and before instantiating the scanner.
Useful? React with 👍 / 👎.
Complete implementation of unified ChainscanClient architecture with standardized chain registry, updated scanners, and comprehensive test coverage. Removes confusing aliases and provides single interface for all blockchain scanners.