apollo_batcher: read class definitions through the class manager in view calls

[asaf-sw]

Batcher::call_contract built its state reader with ApolloReader::new, which leaves
class_reader as None. On that path a Cairo 1 class is read straight from the batcher's
storage, and the batcher records that a class was declared, via append_state_diff, but
never writes the definition: only apollo_central_sync calls append_classes. So
is_declared is true while get_casm_and_sierra returns (None, None), couple_casm_and_sierra
maps that to Ok(None), and the expect in read_casm_and_sierra panics inside the blocking
task, surfacing as an InternalError.

Every view call against a Cairo 1 contract therefore fails. Nothing caught it because
call_contract has no production caller yet and the existing tests inject a DictStateReader,
which never reaches ApolloReader. A Cairo 0 callee is unaffected: its definition travels
inline in the state diff and is served by read_deprecated_casm.

Build the reader with new_with_class_reader instead, passing the class manager the
execution path already uses in block_builder.rs, and thread the runtime handle the
class reader needs to block on it from the blocking task, the way create_block_builder
already takes one.

The new test writes a declaration marker to real storage with no definition behind it and
reads the class back through the factory. It panics at apollo_state.rs:151 without the fix
and passes with it.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

[reviewable-StarkWare]

This change is 

[asaf-sw]

• apollo_batcher: bound in-flight view calls so they cannot exhaust the blocking pool #14972 : 2 dependent PRs (#14942 , #14979 )
• apollo_batcher: read class definitions through the class manager in view calls #14967 👈 (View in Graphite)
• main-v0.14.3

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

[yoavGrs]

@yoavGrs reviewed 1 file and made 3 comments.
Reviewable status: 1 of 6 files reviewed, 3 unresolved discussions (waiting on asaf-sw and matanl-starkware).

---

crates/apollo_batcher/src/batcher.rs line 1572 at r1 (raw file):

/// Maximal wall time a view entry point call may hold the batcher's request slot, which block
/// production shares. Execution is bounded by the view call's resource bounds; the budget is for

Consider skipping the resources and the budget in the comment.

---

crates/apollo_batcher/src/batcher.rs line 1576 at r1 (raw file):

/// retries a 30 second per-attempt timeout up to 150 times in the distributed deployment, and the
/// local client the other deployments use has neither timeout nor retries.
pub(crate) const VIEW_CALL_TIMEOUT: Duration = Duration::from_secs(30);

1. Move both consts to the top of the file.
2. 30 secs sounds a bit long for batch production, no?
3. Consider controlling it by conig.
4. From where come the 150 times? It means we let 150 tasks work concurrently, each task takes 75 minutes.

---

crates/apollo_dashboard/src/panels/blockifier.rs line 30 at r1 (raw file):

    class_cache_metrics: &CacheMetrics,
) -> Panel {
    let scope = class_cache_metrics.get_scope();

1. Consider adding the scope validation of get_scope.
2. Is ' get_scope ' dead code now?

Code quote:

get_scope()

[yoavGrs]

@yoavGrs reviewed 4 files and all commit messages.
Reviewable status: 5 of 6 files reviewed, 3 unresolved discussions (waiting on asaf-sw and matanl-starkware).

[matanl-starkware]

@matanl-starkware reviewed 6 files and all commit messages, and made 1 comment.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on asaf-sw and yoavGrs).

---

crates/apollo_batcher/src/batcher.rs line 1576 at r1 (raw file):

Previously, yoavGrs wrote…

1. Move both consts to the top of the file.
2. 30 secs sounds a bit long for batch production, no?
3. Consider controlling it by conig.
4. From where come the 150 times? It means we let 150 tasks work concurrently, each task takes 75 minutes.

Agree. The timeout should be 5 seconds.

[github-actions]

Artifacts upload workflows:

• Started at 2026-08-16T13:39:18Z
• Started at 2026-08-16T13:43:56Z

[asaf-sw]

@asaf-sw+AGNT made 3 comments.
Reviewable status: 3 of 11 files reviewed, 3 unresolved discussions (waiting on matanl-starkware and yoavGrs).

---

crates/apollo_batcher/src/batcher.rs line 1572 at r1 (raw file):

Previously, yoavGrs wrote…

Consider skipping the resources and the budget in the comment.

Done. VIEW_CALL_TIMEOUT is now a config param and its description says only what it bounds: "Maximal wall time (in milliseconds) a view entry point call may hold the batcher's request slot, which block production shares." Dropped the resource bounds sentence from MAX_VIEW_CALL_RETDATA_LENGTH's doc too.

---

crates/apollo_batcher/src/batcher.rs line 1576 at r1 (raw file):

Previously, matanl-starkware (Matan Lior) wrote…

Agree. The timeout should be 5 seconds.

1. Done. MAX_VIEW_CALL_RETDATA_LENGTH now sits right after the type aliases at the top of the file, and VIEW_CALL_TIMEOUT is gone (see 3).
2. • 3. Both done: it is now batcher_config.dynamic_config.view_call_timeout_millis, default 5000, added to batcher_config.json and replacer_batcher_config.json alongside the schema. Dynamic rather than static so it can be retuned without a redeploy once the endpoint has a caller.
3. From crates/apollo_deployments/resources/services/distributed/batcher.json:

"components.class_manager.remote_client_config.retries": 150

over the default request_timeout_ms of 30000, so a single class read against an unreachable class manager can retry for 75 minutes. Those are sequential retries inside one read, not 150 concurrent tasks. Each view call reads its classes one after another, and the batcher serves requests one at a time, so the batcher's own request slot is what the timeout protects: timing out frees the slot, though the blocking task keeps running on its own thread until the reads give up. #14972 on top of this bounds how many such orphaned tasks can pile up.

---

crates/apollo_dashboard/src/panels/blockifier.rs line 30 at r1 (raw file):

Previously, yoavGrs wrote…

1. Consider adding the scope validation of get_scope.
2. Is ' get_scope ' dead code now?

1. Restored. CacheMetrics::get_scope is now CacheMetrics::validate_scope, which keeps the assert_eq! that misses and hits agree on their scope, and the panel builder calls it first. The dashboard generator runs on every apollo_dashboard test, so a mismatch still fails CI.
2. It was: after this change no caller needed the returned scope. Renaming rather than deleting keeps the assertion.

[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 61e8aa1. Configure here.}

[asaf-sw]

@asaf-sw+AGNT made 1 comment and resolved 1 discussion.
Reviewable status: 2 of 11 files reviewed, 3 unresolved discussions (waiting on matanl-starkware and yoavGrs).

[yoavGrs]

@yoavGrs resolved 3 discussions.
Reviewable status: 2 of 11 files reviewed, all discussions resolved (waiting on matanl-starkware).

[asaf-sw]

@asaf-sw reviewed 11 files and all commit messages.
Reviewable status: 2 of 11 files reviewed, all discussions resolved (waiting on matanl-starkware).

Resolved all comments but is sick and can't continue reviewing.

[matanl-starkware]

@matanl-starkware reviewed 9 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on asaf-sw).