Skip to content

draft: route external Custom chains from the --chain string#359

Open
shahan-khatchadourian-anchorage wants to merge 1 commit into
mainfrom
draft-cli-route-custom-chains
Open

draft: route external Custom chains from the --chain string#359
shahan-khatchadourian-anchorage wants to merge 1 commit into
mainfrom
draft-cli-route-custom-chains

Conversation

@shahan-khatchadourian-anchorage

Copy link
Copy Markdown
Contributor

Problem

parser_cli_core exists so external workspaces can compose their own
parser_cli binary with a custom set of chain plugins (see the crate docs).
A plugin registers its converter under a Chain; a chain without a dedicated
enum variant uses Chain::Custom("name").

But chains::parse_chain maps any unrecognized string to
Chain::Unspecified, and both code paths that turn --chain <string> into a
Chain go through it:

  • plugin selection in run (plugins.iter().find(|p| p.chain() == chain))
  • registry lookup in output::parse_and_display (convert_transaction(&parse_chain(chain), ...))

So a plugin registered under Chain::Custom("foo") can never be selected:
parse_chain("foo") yields Unspecified, which matches neither the plugin
nor its registry entry. The CLI even lists the chain as supported (that list
is built from the plugins) while rejecting it — a confusing contradiction.

Fix

Map unrecognized chain strings to Chain::Custom(string) instead of
Chain::Unspecified, mirroring the existing impl FromStr for Chain
contract. Built-in chains are unaffected (matched first). The plugin that
registered under that Custom chain is now selected, so an external
workspace can add a chain purely by depending on its chain crate — no edit to
upstream chain-string parsing.

Test plan

  • New unit tests in chains.rs: built-ins still map to their variant; an
    unknown string ("near") maps to Chain::Custom("near").
  • cargo test -p parser_cli_core — 28 passed.
  • cargo test -p parser_cli — 8 passed (no existing behavior regressed).
  • make -C src fmt + make -C src lint — clean across the workspace.

🤖 Generated with Claude Code

parse_chain mapped any unrecognized chain string to Chain::Unspecified, so
a chain contributed by an external ChainPlugin -- which registers its
converter under Chain::Custom -- could never be selected: both the plugin
lookup in run() and the registry lookup in parse_and_display() resolve the
requested chain through parse_chain.

Map unrecognized strings to Chain::Custom(string) instead, matching the
existing `impl FromStr for Chain` contract. The plugin that registered under
that Custom chain is now selected, so an external workspace can add a chain
purely by depending on its chain crate -- no edit to upstream chain-string
parsing required, which is the stated purpose of this crate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 3, 2026 14:39

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates parser_cli_core’s chain-string parsing so external/custom chain plugins can be selected via --chain <string> by mapping unknown chain strings to Chain::Custom(<string>) instead of Chain::Unspecified, aligning behavior with the Chain parsing contract and plugin registration expectations.

Changes:

  • Changed parse_chain to return Chain::Custom(chain_str) for unrecognized chain strings.
  • Updated the parse_chain rustdoc to describe the new behavior and rationale.
  • Added unit tests to verify built-in mappings remain stable and unknown strings map to Chain::Custom.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +18 to +20
/// Built-in chains map to their dedicated variant. Any other string maps to
/// `Chain::Custom`, so a chain contributed by an external [`ChainPlugin`] is
/// selected by the plugin that registered under the matching `Chain::Custom`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants