Module download 

Snapshot download command.

reth download prepares a data directory from published snapshot archives. DownloadCommand covers both a single-archive path and a manifest-driven path, and owns the steps required to turn downloaded bytes into a bootable node directory.

Entry modes

DownloadCommand has two main execution modes:

• Single-archive mode processes one .tar.lz4 or .tar.zst archive from --url. Depending on the source and flags, it either extracts a local file:// archive, streams a remote archive straight into extraction, or downloads the archive to disk first and then extracts it.
• Manifest mode resolves a SnapshotManifest, turns CLI or TUI choices into ComponentSelections, plans the required archives, processes them, and then writes the resulting config and database checkpoints.

DownloadDefaults defines the discovery endpoints and default help text used when the command needs to discover a manifest instead of consuming an explicit source.

Selection and planning

Manifest mode first reduces user input into ResolvedComponents: a map of SnapshotComponentType to ComponentSelection plus an optional SelectionPreset. This turns CLI input (minimal, full, archive, or explicit --with-* flags) into the component selections used by the download code.

The selected components are then expanded into PlannedDownloads, which is the set of PlannedArchives that must be verified, downloaded, or reused. Planning also computes the total byte count used by progress reporting.

Archive processing

Each planned archive is processed independently, but DownloadSession holds the shared progress, request limit, and cancellation token for the whole command. ArchiveProcessContext adds the paths needed to process one archive.

Archive processing is modeled around ModularDownloadJob, which schedules work, and ArchiveProcessor, which owns the explicit retry state machine for one archive. ArchiveMode decides whether that archive should be fetched through the cache or streamed directly:

• reuse verified plain output files when possible,
• otherwise fetch and extract the archive,
• verify the declared output files,
• retry the entire archive attempt if extraction succeeded but verification failed.

Reuse and completion are based on verified output files, not on whether an old archive file is present.

Fetch and extraction

stream_and_extract handles the single-archive path. It supports local files, resumable downloads to disk, and direct streaming extraction.

When the code needs to fetch an archive to disk, it uses ArchiveFetcher. The fetcher probes the remote source and chooses between a sequential download and a segmented download plan (SegmentedDownloadPlan). SequentialDownloadFallback records why a source could not use the segmented path, while SegmentedDownload runs the worker queue and piece retries for the parallel path.

Segmented download retries individual byte ranges. Archive processing retries whole-archive attempts. These are separate layers: range retries deal with transient request failures, while archive retries deal with extraction or output verification failures.

CompressionFormat determines how the archive stream is unpacked once bytes are available, and OutputVerifier checks the extracted output files before reuse or completion.

Progress and finalization

DownloadProgress reports progress for the single-archive path. SharedProgress reports aggregate progress for modular downloads. It tracks fetched bytes separately from completed bytes so repeated fetches during retries do not overstate completion.

After all required archives are complete, DownloadCommand finalizes the directory by writing the derived node configuration and updating prune or index-stage checkpoints. A successful command leaves a data directory that matches the snapshot shape that was selected.

Modules

config_gen

manifest

manifest_cmd

Structs

DownloadCommand

CLI command that downloads snapshot archives and configures a reth node from them.

DownloadDefaults

Download configuration defaults