apollo_integration_tests: store the commitment infos delta in the dummy recorder

[itamar-starkware]

No description provided.

[cursor]

PR Summary

Low Risk
Changes are confined to apollo_integration_tests test utilities and dummy HTTP recorder behavior; production sequencer code is untouched.

Overview
Integration tests replace the no-op dummy cende recorder with one that mirrors the production commitment-infos height-offset contract so blob sends advance incrementally instead of always replaying the full recent-blocks window.

On each write_blob, the handler parses recent_state_commitment_infos block numbers, updates a served offset, and records invalid heights when arrivals are not contiguous from the expected offset (retries and empty first blobs are handled). The offset endpoint returns the live offset instead of a fixed null, and axum’s default 2MB body limit is disabled for large blobs.

RecorderStats is returned from spawn_local_success_recorder and exposed on FlowSequencerSetup so flow tests can assert recorder behavior; the shared integration-test manager spawn discards stats for now.

^{Reviewed by Cursor Bugbot for commit eba828e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[reviewable-StarkWare]

This change is 

[itamar-starkware]

• apollo_integration_tests: verify Patricia storage proofs of persisted witnesses in flow tests #14905
• apollo_integration_tests: assert witness-carrying cende blobs reach the recorder in flow tests #14918
• apollo_integration_tests: store the commitment infos delta in the dummy recorder #14935 👈 (View in Graphite)
• apollo_integration_tests: assert witnesses persisted for committed heights in flow tests #14903 : 1 other dependent PR (#14904 )
• central_systest_blobs: publish a decoded commitment-infos companion beside the blobs #14917
• central_systest_blobs: carry real witness fields in the regression blobs #14910
• central_systest_blobs: generalize the GCS helpers to fetch and upload arbitrary objects #14920
• workspace,ci: remove the os_input feature (make it unconditional) #14902 : 2 other dependent PRs (#14907 , #14909 )
• main

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.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 3b33448. Configure here.}

[itamar-starkware]

@itamar-starkware made 1 comment.
Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on yoavGrs).

[yoavGrs]

@yoavGrs made 1 comment.
Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on itamar-starkware).

---

crates/apollo_integration_tests/src/utils.rs line 598 at r1 (raw file):

#[derive(Debug, Default)]
pub struct RecorderStats {
    pub num_blobs_received: AtomicUsize,

Please keep it simple.

I suggest storing the offset and a map from invalid block_number to reason.
Is there any validation that this does not cover?

[yoavGrs]

@yoavGrs made 1 comment.
Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on itamar-starkware).

---

crates/apollo_integration_tests/src/utils.rs line 619 at r2 (raw file):

                        // A blob is prepared before its own height's commitment completes, so
                        // early blobs legitimately carry no commitment infos.
                        if let Some(max_stored_height) = blob["recent_state_commitment_infos"]

I suggested validating the witnesses' heights in the blob against the stored offset.
You can report any issue in a dedicated field.

[yoavGrs]

@yoavGrs resolved 1 discussion.
Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on itamar-starkware).

[yoavGrs]

@yoavGrs made 1 comment and resolved 1 discussion.
Reviewable status: 0 of 3 files reviewed, 1 unresolved discussion (waiting on itamar-starkware).

---

crates/apollo_integration_tests/src/utils.rs line 608 at r3 (raw file):

        let Some(first_height) = heights.first() else { return };
        let mut height_offset = self.commitment_infos_height_offset.lock().unwrap();
        // Consensus rebuilds its proposal on a later round, re-sending a blob whose heights the

        // Consensus rebuilds its proposal on a later round, re-sending a blob whose heights the
        // recorder already stored.

Does it happen?

[itamar-starkware]

crates/apollo_integration_tests/src/utils.rs line 619 at r2 (raw file):

Previously, yoavGrs wrote…

I suggested validating the witnesses' heights in the blob against the stored offset.
You can report any issue in a dedicated field.

Done

[itamar-starkware]

crates/apollo_integration_tests/src/utils.rs line 598 at r1 (raw file):

Previously, yoavGrs wrote…

Please keep it simple.

I suggest storing the offset and a map from invalid block_number to reason.
Is there any validation that this does not cover?

Done, using expected_height

[yoavGrs]

@yoavGrs reviewed 3 files and all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on itamar-starkware).

[itamar-starkware]

@itamar-starkware made 1 comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on yoavGrs).

---

crates/apollo_integration_tests/src/utils.rs line 608 at r3 (raw file):

Previously, yoavGrs wrote…

        // Consensus rebuilds its proposal on a later round, re-sending a blob whose heights the
        // recorder already stored.

Does it happen?

The re-send is a real case. The comment was not accurate - changing it now.

[yoavGrs]

@yoavGrs reviewed 1 file and all commit messages, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on itamar-starkware).