feat: add abstract rpc configuration in localnet guide + foreign policy serialization fix by netrome · Pull Request #2180 · near/mpc

netrome · 2026-02-19T13:19:55Z

Additionally, this PR also adds configuration for Starknet and two small broken-window fixes:

Abstract wasn't listed as a supported chain.
The foreign policy config serialized a bunch of null fields.

netrome · 2026-02-19T13:20:25Z

crates/node/src/coordinator.rs

+            dtos::ForeignChain::Abstract
+                | dtos::ForeignChain::Solana


This is the broken-window fix

strange that we missed this, didn't we have an end2end test for Abstract?

netrome · 2026-02-19T13:21:05Z

docs/localnet/args/verify_foreign_tx_starknet.json

+    "request": {
+        "request": {
+            "Starknet": {
+                "tx_id": "025c84e568751d2e3189357b3f48690e4e987084204bc82ebde1d51ec3948fd8",


This will probably not work after some time as starknet RPCs may not serve all txs forever, but adding some "refresh" or query script to generate these args felt out of scope for now.

claude · 2026-02-19T13:22:20Z

PR title type suggestion: This PR modifies a source code file (crates/node/src/coordinator.rs) along with documentation files. If the coordinator change includes logic or configuration modifications, consider using feat: or chore: instead of docs:.
Suggested title: feat: add abstract rpc configuration in localnet guide (if adding new functionality) or chore: add abstract rpc configuration support (if routine maintenance).

claude · 2026-02-19T13:22:42Z

PR title type suggestion: This PR modifies source code in crates/node/src/coordinator.rs alongside documentation changes. If these changes add new RPC configuration functionality, the type prefix should probably be feat: instead of docs:.
Suggested title: feat: add abstract rpc configuration in localnet guide

claude · 2026-02-19T13:23:45Z

Code Review

This PR adds Abstract and Starknet RPC configuration to the localnet guide, adds a Starknet foreign tx verification args file, and fixes a bug where Abstract was missing from is_supported_foreign_chain.

Potential Issue

is_supported_foreign_chain is a manual allowlist without exhaustive matching (coordinator.rs:787-796)

The ForeignChain enum has 8 variants (Solana, Bitcoin, Ethereum, Base, Bnb, Arbitrum, Abstract, Starknet), but is_supported_foreign_chain only matches 5 of them. The fact that Abstract was missing until this "broken-window fix" demonstrates the fragility of this approach — every time a new variant is added to ForeignChain, someone must remember to update this function.

Since the enum is #[non_exhaustive], an exhaustive match isn't possible from outside the defining crate. However, consider one of:

Explicitly return false for the unsupported variants and add a wildcard with a comment, making it clear which chains are intentionally unsupported:

fn is_supported_foreign_chain(chain: &dtos::ForeignChain) -> bool {
    match chain {
        dtos::ForeignChain::Abstract
        | dtos::ForeignChain::Solana
        | dtos::ForeignChain::Bitcoin
        | dtos::ForeignChain::Ethereum
        | dtos::ForeignChain::Starknet => true,
        // Intentionally unsupported:
        dtos::ForeignChain::Base
        | dtos::ForeignChain::Bnb
        | dtos::ForeignChain::Arbitrum => false,
        // Non-exhaustive catch-all for future variants
        _ => false,
    }
}

This way, when a new variant is added, it falls to the wildcard and is explicitly unsupported rather than silently dropped. More importantly, the intent is documented.

Add a unit test for the unsupported variants to make the intent explicit and ensure it's reviewed when new variants are added.

This is not a merge blocker given the existing code already had this pattern, but it's worth addressing since this PR is literally fixing the exact class of bug this pattern enables.

Minor note

The test is_supported_foreign_chain__supports_abstract follows the project convention from CONTRIBUTING.md but uses supports_ instead of should_support_. The existing starknet test uses the same pattern, so this is consistent within the file. Not a blocker.

No other critical issues found. The docs changes, config template updates, and the bug fix with its accompanying test all look correct.

✅

netrome · 2026-02-19T13:24:20Z

PR title type suggestion: This PR modifies source code in crates/node/src/coordinator.rs alongside documentation changes. If these changes add new RPC configuration functionality, the type prefix should probably be feat: instead of docs:. Suggested title: feat: add abstract rpc configuration in localnet guide

Nah, that's a broken-window fix. Could be broken out but this is mainly a docs PR.

netrome · 2026-02-19T13:27:17Z

Code Review

This PR adds Abstract and Starknet RPC configuration to the localnet guide, adds a Starknet foreign tx verification args file, and fixes a bug where Abstract was missing from is_supported_foreign_chain.

Potential Issue

is_supported_foreign_chain is a manual allowlist without exhaustive matching (coordinator.rs:787-796)

The ForeignChain enum has 8 variants (Solana, Bitcoin, Ethereum, Base, Bnb, Arbitrum, Abstract, Starknet), but is_supported_foreign_chain only matches 5 of them. The fact that Abstract was missing until this "broken-window fix" demonstrates the fragility of this approach — every time a new variant is added to ForeignChain, someone must remember to update this function.

Since the enum is #[non_exhaustive], an exhaustive match isn't possible from outside the defining crate. However, consider one of:
1. **Explicitly return `false` for the unsupported variants and add a wildcard with a comment**, making it clear which chains are intentionally unsupported:
   ```rust
   fn is_supported_foreign_chain(chain: &dtos::ForeignChain) -> bool {
       match chain {
           dtos::ForeignChain::Abstract
           | dtos::ForeignChain::Solana
           | dtos::ForeignChain::Bitcoin
           | dtos::ForeignChain::Ethereum
           | dtos::ForeignChain::Starknet => true,
           // Intentionally unsupported:
           dtos::ForeignChain::Base
           | dtos::ForeignChain::Bnb
           | dtos::ForeignChain::Arbitrum => false,
           // Non-exhaustive catch-all for future variants
           _ => false,
       }
   }
   ```
   
   
       
         
       
   
         
       
   
       
     
   This way, when a new variant is added, it falls to the wildcard and is explicitly unsupported rather than silently dropped. More importantly, the intent is documented.

2. **Add a unit test for the unsupported variants** to make the intent explicit and ensure it's reviewed when new variants are added.
This is not a merge blocker given the existing code already had this pattern, but it's worth addressing since this PR is literally fixing the exact class of bug this pattern enables.

Minor note

The test is_supported_foreign_chain__supports_abstract follows the project convention from CONTRIBUTING.md but uses supports_ instead of should_support_. The existing starknet test uses the same pattern, so this is consistent within the file. Not a blocker.

No other critical issues found. The docs changes, config template updates, and the bug fix with its accompanying test all look correct.

✅

Thanks, you make some good points - but the concrete suggestions doesn't seem to improve the situation as it would still be easy to "forget" about this change and they don't provide compile time guarantees. We should focus on better and more comprehensive testing instead imo.

netrome · 2026-02-19T13:32:35Z

crates/node/src/config/foreign_chains.rs

 pub struct ForeignChainsConfig {
-    #[serde(default)]
+    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub solana: Option<SolanaChainConfig>,
-    #[serde(default)]
+    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub bitcoin: Option<BitcoinChainConfig>,
-    #[serde(default)]
+    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub ethereum: Option<EthereumChainConfig>,
-    #[serde(default)]
+    #[serde(default, skip_serializing_if = "Option::is_none")]
    #[serde(rename = "abstract")]
    pub abstract_chain: Option<AbstractChainConfig>,
-    #[serde(default)]
+    #[serde(default, skip_serializing_if = "Option::is_none")]
    pub starknet: Option<StarknetChainConfig>,


Another unrelated broken-window fix. I noted a bunch of ethereum: null and solana: null fields appearing in the config. Don't know where we write to the config file, but let's primarily just not add these.

Ah I see we added this for the web_ui host+port to SocketAddr change, that explains why we're writing to the config. Fair enough.

claude · 2026-02-19T13:32:55Z

PR title type suggestion: This PR modifies source code files (crates/node/src/) in addition to documentation, so the type prefix should probably be feat: instead of docs:.
Suggested title: feat: add abstract rpc configuration support

gilcu3

Thank you!

claude · 2026-02-19T14:05:36Z

PR title type suggestion: This PR adds new source code functionality for Abstract chain RPC configuration support across multiple files (foreign_chains.rs, coordinator.rs). While documentation is included, the primary intent is implementing a new feature. The type prefix should probably be feat: instead of docs:.

Suggested title: feat: add abstract rpc configuration support

netrome · 2026-02-19T14:05:57Z

pytest/common_lib/shared/foreign_chains.py

    # Keep generated YAML tags intact by editing only the trailing `foreign_chains` section.
    config_text = (
-        re.sub(r"\nforeign_chains:\n[\s\S]*\Z", "\n", config_text).rstrip() + "\n"
+        re.sub(r"\nforeign_chains:[\s\S]*\Z", "\n", config_text).rstrip() + "\n"


Needed because the serialization format changed now. This would look like foreign_chains: {}

crates/node/src/config/foreign_chains.rs

netrome self-assigned this Feb 19, 2026

netrome linked an issue Feb 19, 2026 that may be closed by this pull request

Add abstract RPC configuration in localnet guide #2177

Closed

netrome commented Feb 19, 2026

View reviewed changes

netrome marked this pull request as ready for review February 19, 2026 13:21

netrome added 3 commits February 19, 2026 14:21

docs: Localnet update to support abstract

65a947e

docs: Add starknet extractor

f8358b9

fix: is_supported_chain should support Abstract

4268e58

netrome force-pushed the 2177-add-abstract-rpc-configuration-in-localnet-guide branch from 83ba95f to 4268e58 Compare February 19, 2026 13:21

fix: Don't serialize unset configurations

bfe17cd

netrome commented Feb 19, 2026

View reviewed changes

gilcu3 previously approved these changes Feb 19, 2026

View reviewed changes

fix: Pytest serialization fix

55e6d99

netrome dismissed gilcu3’s stale review via 55e6d99 February 19, 2026 14:04

netrome commented Feb 19, 2026

View reviewed changes

DSharifi approved these changes Feb 19, 2026

View reviewed changes

crates/node/src/config/foreign_chains.rs Show resolved Hide resolved

netrome changed the title ~~docs: add abstract rpc configuration in localnet guide~~ feat: add abstract rpc configuration in localnet guide + foreign policy serialization fix Feb 19, 2026

netrome enabled auto-merge February 19, 2026 14:12

gilcu3 approved these changes Feb 19, 2026

View reviewed changes

netrome added this pull request to the merge queue Feb 19, 2026

Merged via the queue into main with commit ea2e6a1 Feb 19, 2026
14 checks passed

netrome deleted the 2177-add-abstract-rpc-configuration-in-localnet-guide branch February 19, 2026 14:55

Conversation

netrome commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netrome Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

gilcu3 Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

netrome Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

claude bot commented Feb 19, 2026

Uh oh!

claude bot commented Feb 19, 2026

Uh oh!

claude bot commented Feb 19, 2026

Code Review

Potential Issue

Minor note

Uh oh!

netrome commented Feb 19, 2026

Uh oh!

netrome commented Feb 19, 2026

Code Review

Potential Issue

Minor note

Uh oh!

netrome Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

netrome Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

claude bot commented Feb 19, 2026

Uh oh!

gilcu3 left a comment

Choose a reason for hiding this comment

Uh oh!

claude bot commented Feb 19, 2026

Uh oh!

netrome Feb 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

netrome commented Feb 19, 2026 •

edited

Loading

gilcu3 Feb 19, 2026 •

edited

Loading