apollo_propeller: add reconstruction types and spawn task

[sirandreww-starkware]

Note

Low Risk
Mostly additive, currently unused reconstruction scaffolding and a minor dependency feature tweak; limited behavior change unless/when wired into the processing flow.

Overview
Adds scaffolding in MessageProcessor for erasure-coded message reconstruction: introduces ReconstructionResult/ReconstructionSuccess types and a spawn_reconstruction_task helper that runs reconstruct_message_from_shards on the Rayon pool and returns the result via a oneshot channel.

Updates dependencies to enable rand’s std/std_rng features and adjusts imports to include reconstruction-related types (ReconstructionError, MerkleProof).

^{Written by Cursor Bugbot for commit 21443c9. This will update automatically on new commits. Configure here.}

[reviewable-StarkWare]

This change is 

[github-actions]

Artifacts upload workflows:

• Started at 2026-01-26T14:10:17Z
• Started at 2026-02-04T11:54:30Z
• Started at 2026-02-08T15:06:59Z
• Started at 2026-02-08T15:07:08Z
• Started at 2026-02-09T14:28:08Z
• Started at 2026-02-22T07:36:56Z

[sirandreww-starkware]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• apollo_propeller: add channel closure handling #12011
• apollo_propeller: add PostReconstruction phase and threshold checking #12010
• apollo_propeller: add reconstruction result handling #12009
• apollo_propeller: add PreReconstruction phase and shard collection #12008
• apollo_propeller: add reconstruction types and spawn task #12007 👈 (View in Graphite)
• apollo_propeller: add validated unit handling and shard broadcasting #12006
• apollo_propeller: add validation result handling #12005
• apollo_propeller: add unit validation receiving and spawning #12004
• apollo_propeller: add MessageProcessor scaffolding #12003 : 1 other dependent PR (#12780 )
• apollo_propeller: added shard index utility functions to schedule manager #12002
• apollo_propeller: add sharding module with tests #11944 : 1 other dependent PR (#12001 )
• apollo_propeller: add message padding utilities #11943
• apollo_propeller: add behaviour public API stubs #11942
• apollo_propeller: add minimal config #11196 : 1 other dependent PR (#11197 )
• apollo_propeller: add behaviour skeleton #11195
• apollo_propeller: add Event enum to types #11194
• apollo_propeller: add dial upgrade error handling to handler #11074
• apollo_propeller: add rate-limited queue length warnings #11073
• apollo_propeller: add concurrent streams support to handler #11072
• apollo_propeller: implement outbound substream with message batching #11071
• apollo_propeller: add handler helper methods #11070
• main-v0.14.2

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

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[guy-starkware]

@guy-starkware reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @noamsp-starkware, @ShahakShama, and @sirandreww-starkware).

---

crates/apollo_propeller/src/message_processor.rs line 220 at r1 (raw file):

        rayon::spawn(move || {
            let result =
                rebuild_message(shards, message_root, my_shard_index, data_count, coding_count)

Is there a reason rebuild_message doesn't just emit ReconstructionResult?

[guy-starkware]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on noamsp-starkware, ShahakShama, and sirandreww-starkware).

[sirandreww-starkware]

@sirandreww-starkware made 2 comments and resolved 1 discussion.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on guy-starkware, noamsp-starkware, and ShahakShama).

---

crates/apollo_propeller/src/message_processor.rs line 220 at r1 (raw file):

Previously, guy-starkware wrote…

Is there a reason rebuild_message doesn't just emit ReconstructionResult?

AI answer:
reconstruct_message_from_shards lives in the sharding utility layer — it only knows about erasure coding, Merkle trees, and padding. ReconstructionSuccess (and ReconstructionResult) are processor-level concepts private to MessageProcessor, where the tuple fields get domain-specific names (my_shard, my_shard_proof) tied to the node's role. Pushing that type down into sharding.rs would couple the generic reconstruction logic to the processor's internal model. Keeping the tuple return keeps the sharding layer composable and the boundary clean.

My answer:
I don't want spinoff workers to emit events, the message processor both 1) needs to know the result of the build to update its state and 2) needs to figure out what to emit, or if to emit in the first place.

[sirandreww-starkware]

@sirandreww-starkware resolved 1 discussion.
Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on guy-starkware, noamsp-starkware, and ShahakShama).

[sirandreww-starkware]

@sirandreww-starkware partially reviewed 3 files.
Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on guy-starkware, noamsp-starkware, and ShahakShama).

[guy-starkware]

@guy-starkware reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on noamsp-starkware and ShahakShama).

---

crates/apollo_propeller/src/message_processor.rs line 220 at r1 (raw file):

Previously, sirandreww-starkware (Andrew Luka) wrote…

AI answer:
reconstruct_message_from_shards lives in the sharding utility layer — it only knows about erasure coding, Merkle trees, and padding. ReconstructionSuccess (and ReconstructionResult) are processor-level concepts private to MessageProcessor, where the tuple fields get domain-specific names (my_shard, my_shard_proof) tied to the node's role. Pushing that type down into sharding.rs would couple the generic reconstruction logic to the processor's internal model. Keeping the tuple return keeps the sharding layer composable and the boundary clean.

My answer:
I don't want spinoff workers to emit events, the message processor both 1) needs to know the result of the build to update its state and 2) needs to figure out what to emit, or if to emit in the first place.

ok. I am not familiar enough with the logical boundaries, but if you think this is better I will go with it.

[ShahakShama]

@ShahakShama made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on noamsp-starkware and sirandreww-starkware).

---

crates/apollo_propeller/Cargo.toml line 19 at r3 (raw file):

libp2p.workspace = true
prost.workspace = true
rand = { workspace = true, features = ["std", "std_rng"] }

Why?

[ShahakShama]

@ShahakShama reviewed all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on noamsp-starkware and sirandreww-starkware).