Problem
analyze applies --max-events before chunk expansion. In default chunk mode, each parsed event can expand to as many as 4096 chunk events in to_blocks. The per-access cap prevents a single line from exploding without bound, but the aggregate expanded trace can still be very large.
The default cap is 3,000,000 input events. In the worst case, that can still materialize a very large block trace before the sweep runs.
Impact
This is an efficiency and memory-risk issue for large-object or large-range workloads in default chunk mode. --max-events sounds like a hard analysis bound, but it does not bound the post-expansion workload the replay ladder sees.
Expected direction
Consider a separate max expanded events or max expanded blocks guard, streaming expansion into the sweeps, or clearer documentation that --max-events caps parsed input events only.
Relevant paths
- crates/s3tap-advisor/src/analyze.rs::analyze_trace
- crates/s3tap-replay/src/ibm.rs::to_blocks
- crates/s3tap-cli/src/main.rs::AnalyzeArgs
Problem
analyze applies --max-events before chunk expansion. In default chunk mode, each parsed event can expand to as many as 4096 chunk events in to_blocks. The per-access cap prevents a single line from exploding without bound, but the aggregate expanded trace can still be very large.
The default cap is 3,000,000 input events. In the worst case, that can still materialize a very large block trace before the sweep runs.
Impact
This is an efficiency and memory-risk issue for large-object or large-range workloads in default chunk mode. --max-events sounds like a hard analysis bound, but it does not bound the post-expansion workload the replay ladder sees.
Expected direction
Consider a separate max expanded events or max expanded blocks guard, streaming expansion into the sweeps, or clearer documentation that --max-events caps parsed input events only.
Relevant paths