Panic when checking storage consistency using exec example on archive snapshot datadir

[0xalex88]

Describe the bug

I'm writing an exex and I'm trying to run it on an archive node datadir but I'm getting this error during Verifying storage consistency:

thread 'main' panicked at /usr/local/cargo/git/checkouts/reth-36d3ea1d1152b20c/d97449d/crates/storage/codecs/src/lib.rs:198:52:
range end index 8572 out of range for slice of length 255

What I've tried:

• reth 1.1.4 docker image using the archive datadir: works
• reth 1.1.4 docker image using the full node snapshot datadir: works
• the exex code against the full node snapshot datadir: works
• the exec code against the archive node snapshot datadir: throws the error above

This is the code (using 1.1.4 tag for the cargo dependencies):

use dotenv::dotenv;
use crate::myexex::MyExEx;
use reth_node_ethereum::EthereumNode;

fn main() -> eyre::Result<()> {
    dotenv().ok();

    reth::cli::Cli::parse_args().run(|builder, _| async move {
        let handle = builder
            .node(EthereumNode::default())
            .install_exex("FUI", move |ctx| async { Ok(MyExEx::new(ctx).start()) })
            .launch()
            .await?;

        handle.wait_for_node_exit().await
    })
}

and I've also tried to launch it how the current reth executable does (without the legacy flag handling since I don't use it):

use dotenv::dotenv;
use fui_reth::fui::FuiExEx;
use reth::{
    builder::{
        engine_tree_config::{
            TreeConfig, DEFAULT_MEMORY_BLOCK_BUFFER_TARGET, DEFAULT_PERSISTENCE_THRESHOLD,
        },
        EngineNodeLauncher,
    },
    providers::providers::BlockchainProvider2,
};
use reth_node_ethereum::{node::EthereumAddOns, EthereumNode};

fn main() -> eyre::Result<()> {
    dotenv().ok();

    reth_cli_util::sigsegv_handler::install();

    // Enable backtraces unless a RUST_BACKTRACE value has already been explicitly provided.
    if std::env::var_os("RUST_BACKTRACE").is_none() {
        std::env::set_var("RUST_BACKTRACE", "1");
    }

    reth::cli::Cli::parse_args().run(|builder, _| async move {
        let engine_tree_config = TreeConfig::default()
            .with_persistence_threshold(DEFAULT_PERSISTENCE_THRESHOLD)
            .with_memory_block_buffer_target(DEFAULT_MEMORY_BLOCK_BUFFER_TARGET);

        let handle = builder
            .with_types_and_provider::<EthereumNode, BlockchainProvider2<_>>()
            .with_components(EthereumNode::components())
            .with_add_ons(EthereumAddOns::default())
            .install_exex("FUI", move |ctx| async { Ok(FuiExEx::new(ctx).start()) })
            .launch_with_fn(|builder| {
                let launcher = EngineNodeLauncher::new(
                    builder.task_executor().clone(),
                    builder.config().datadir(),
                    engine_tree_config,
                );
                builder.launch_with(launcher)
            })
            .await?;

        handle.wait_for_node_exit().await
    })
}

I've also tried to remove the exex install part and the dotenv loading (I use it in the exex) but didn't made a difference.

Steps to reproduce

1. Download a public archive node snapshot from publicnode/merkle
2. Start the exex with the code above

Node logs

2024-12-12T00:45:36.544905Z  INFO Initialized tracing, debug log directory: /root/.cache/reth/logs/mainnet
2024-12-12T00:45:36.746153Z  INFO Starting reth version="1.1.3-dev (d97449da)"
2024-12-12T00:45:36.746181Z  INFO Opening database path="/data/execution/db"
2024-12-12T00:45:36.751303Z  INFO Configuration loaded path="/data/execution/reth.toml"
2024-12-12T00:45:36.754119Z  INFO Verifying storage consistency.
thread 'main' panicked at /usr/local/cargo/git/checkouts/reth-36d3ea1d1152b20c/d97449d/crates/storage/codecs/src/lib.rs:198:52:
range end index 8572 out of range for slice of length 255
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_end_index_len_fail
   3: <alloc::vec::Vec<T> as reth_codecs::Compact>::from_compact
   4: <reth_primitives::receipt::Receipt as reth_codecs::Compact>::from_compact
   5: reth_db_api::models::<impl reth_db_api::table::Decompress for reth_primitives::receipt::Receipt>::decompress
   6: reth_db::tables::utils::decoder
   7: reth_provider::providers::static_file::manager::StaticFileProvider<N>::check_consistency
   8: <reth_node_builder::launch::DefaultNodeLauncher as reth_node_builder::launch::LaunchNode<reth_node_builder::builder::states::NodeBuilderWithComponents<T,CB,AO>>>::launch_node::{{closure}}
   9: <core::pin::Pin<P> as core::future::future::Future>::poll
  10: tokio::runtime::runtime::Runtime::block_on
  11: reth::cli::Cli<C,Ext>::run
  12: reth::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
reth-1 exited with code 0

Platform(s)

Linux (x86)

Container Type

Docker, Not running in a container

What version/commit are you on?

1.1.4

What database version are you on?

2

Which chain / network are you on?

mainnet

What type of node are you running?

Archive (default)

What prune config do you use, if any?

No response

If you've built Reth from source, provide the full command you used

Used the repo dockerfile

Code of Conduct

• I agree to follow the Code of Conduct

[0xalex88]

Update: I've found the problem, I had multiple binaries, the other one being the OP version of reth (so using reth_optimism_cli instead of reth::cli::Cli).
I saw that deleting that binary wasn't enough, but ultimately removing reth-optimism-cli from the main Cargo.toml fixed it.

Is it something expected/obvious to happen? I thought that using different cli parsers and node components would've been enough

Update # 2:

I think adding the optimism feature in this case enables reth-codecs/op breaking mainnet.

I'll close it since I guess it'e expected and the build of the op version should be separate