blockifier_reexecution: allow custom chain id

[AvivYossef-starkware]

No description provided.

[reviewable-StarkWare]

This change is 

[github-actions]

Artifacts upload workflows:

• Started at 2025-12-08T15:34:04Z
• Started at 2025-12-10T08:16:25Z
• Started at 2025-12-10T08:19:14Z
• Started at 2025-12-10T11:34:45Z
• Started at 2025-12-10T11:49:07Z
• Started at 2025-12-10T11:49:17Z
• Started at 2025-12-10T13:23:12Z
• Started at 2025-12-10T14:56:34Z
• Started at 2025-12-11T08:00:33Z
• Started at 2025-12-11T08:38:51Z
• Started at 2025-12-11T08:52:37Z

[AvivYossef-starkware]

• blockifier_reexecution: split execute tx logic #10844 : 2 dependent PRs (#10849 , #10855 )
• starknet_os_runner: initialize the crate #10718
• blockifier_reexecution: move files location #10717
• blockifier_reexecution: rename test state reader #10716
• blockifier_reexecution: move reexecute block for testing #10709
• blockifier_reexecution: move write_block reexecution data to file #10708
• blockifier_reexecution: move execute single tx from utils #10707
• blockifier_reexecution: seperate reexecute block from verify correctness #10706
• blockifier_reexecution: move reexecute and verify correctness to trait #10705
• blockifier_reexecution: allow custom chain id #10643 👈 (View in Graphite)
• blockifier_reexecution: use StateReaderAndContractManager in reexecut… #10425
• blockifier_reexecution: impl FetchedCompiledClass for test and offlin… #10330
• main-v0.14.1

This stack of pull requests is managed by Graphite. Learn more about stacking.

[dorimedini-starkware]

@dorimedini-starkware reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @AvivYossef-starkware)

---

crates/blockifier_reexecution/src/state_reader/cli.rs line 34 at r1 (raw file):

    #[clap(long, short = 'c')]
    pub chain_id: Option<ChainId>,
}

suggestion: use ArgGroup to allow two distinct argument types:

1. --chain_id - same as before, using the enum
2. --custom_chain_id - accepting a hex string. you can use the logic in deserialize_chain_id_from_hex to parse this

WDYT?

Code quote:

#[derive(Clone, Debug, Args)]
pub struct RpcArgs {
    /// Node url.
    #[clap(long, short = 'n')]
    pub node_url: String,

    /// Optional chain ID (if not provided, it will be guessed from the node url).
    /// Standard chain IDs: SN_MAIN, SN_SEPOLIA, SN_INTEGRATION_SEPOLIA.
    /// Custom chain IDs are also supported.
    #[clap(long, short = 'c')]
    pub chain_id: Option<ChainId>,
}

---

crates/starknet_api/src/core.rs line 90 at r1 (raw file):

        Ok(Self::from(s.to_owned()))
    }
}

I really don't like that the Other variant of ChainId is a string and not a Felt...
you now have two methods of converting from string to chain ID: this one (which actually treats the string as bytes when converting to Felt), and deserialize_chain_id_from_hex, which treats the string as a hex integer.
can you delete this FromStr implementation to avoid confusion?

Code quote:

impl std::str::FromStr for ChainId {
    type Err = std::convert::Infallible;

    fn from_str(s: &str) -> Result<Self, Self::Err> {
        Ok(Self::from(s.to_owned()))
    }
}

[AvivYossef-starkware]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware)

---

crates/starknet_api/src/core.rs line 90 at r1 (raw file):

Previously, dorimedini-starkware wrote…

I really don't like that the Other variant of ChainId is a string and not a Felt...
you now have two methods of converting from string to chain ID: this one (which actually treats the string as bytes when converting to Felt), and deserialize_chain_id_from_hex, which treats the string as a hex integer.
can you delete this FromStr implementation to avoid confusion?

Maybe the from str should be deserialize_chain_id_from_hex?
What do you think?

[dorimedini-starkware]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @AvivYossef-starkware)

---

crates/starknet_api/src/core.rs line 90 at r1 (raw file):

Previously, AvivYossef-starkware wrote…

Maybe the from str should be deserialize_chain_id_from_hex?
What do you think?

I think it's ambiguous.
the root of the problem is that we have Other(String) instead of Other(Felt), but changing that seems hard (for sure it's out of scope of the current PR).
why not use my above suggestion, and explicitly request a hex string for custom chain IDs? then convert explicitly using deserialize_chain_id_from_hex?

[dorimedini-starkware]

@dorimedini-starkware reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @AvivYossef-starkware)

[AvivYossef-starkware]

Reviewable status: 1 of 4 files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware)

---

crates/blockifier_reexecution/src/state_reader/cli.rs line 34 at r1 (raw file):

Previously, dorimedini-starkware wrote…

suggestion: use ArgGroup to allow two distinct argument types:

1. --chain_id - same as before, using the enum
2. --custom_chain_id - accepting a hex string. you can use the logic in deserialize_chain_id_from_hex to parse this

WDYT?

Done

---

crates/starknet_api/src/core.rs line 90 at r1 (raw file):

Previously, dorimedini-starkware wrote…

I think it's ambiguous.
the root of the problem is that we have Other(String) instead of Other(Felt), but changing that seems hard (for sure it's out of scope of the current PR).
why not use my above suggestion, and explicitly request a hex string for custom chain IDs? then convert explicitly using deserialize_chain_id_from_hex?

Done.

[dorimedini-starkware]

@dorimedini-starkware reviewed 4 of 4 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @AvivYossef-starkware)

---

crates/blockifier_reexecution/src/state_reader/cli.rs line 69 at r3 (raw file):

            let mut deserializer = serde_json::Deserializer::from_str(&json_str);
            return deserialize_chain_id_from_hex(&mut deserializer)
                .expect("Failed to parse hex chain id");

maybe better to extract the string-parsing logic from the deserializer, and using it in two places, instead of creating temporary JSON just to reuse deserialization

Code quote:

            let json_str = format!("\"{}\"", hex_str);
            let mut deserializer = serde_json::Deserializer::from_str(&json_str);
            return deserialize_chain_id_from_hex(&mut deserializer)
                .expect("Failed to parse hex chain id");

[AvivYossef-starkware]

Reviewable status: 2 of 6 files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware)

---

crates/blockifier_reexecution/src/state_reader/cli.rs line 69 at r3 (raw file):

Previously, dorimedini-starkware wrote…

maybe better to extract the string-parsing logic from the deserializer, and using it in two places, instead of creating temporary JSON just to reuse deserialization

Done.

[dorimedini-starkware]

@dorimedini-starkware reviewed 4 of 4 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @AvivYossef-starkware)

---

a discussion (no related file):
ah... risky, doing this on main-v0.14.1... can you open a py-side PR to make sure nothing breaks?

[dorimedini-starkware]

@dorimedini-starkware reviewed 6 of 6 files at r6, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @AvivYossef-starkware)

[AvivYossef-starkware]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @AvivYossef-starkware)

---

a discussion (no related file):

Previously, dorimedini-starkware wrote…

ah... risky, doing this on main-v0.14.1... can you open a py-side PR to make sure nothing breaks?

done