Problem Statement

When running multi-rate benchmark profiles (constant, poisson, concurrent, and the async phase of sweep), benchmarking continues at higher rates even after a lower rate has already hit a failure constraint (for example over-saturation or excessive errors).

This wastes benchmark time, adds low-signal data at clearly unsustainable rates, and can place unnecessary load on the target system.

Proposed Solution

• Treat scheduler constraints with request_processing=stop_all as terminal for rate escalation.
• Sort configured rates/streams ascending for deterministic escalation.
• For multi-rate profiles, stop generating higher-rate strategies after the first terminal failure.
• Keep normal completion constraints (stop_local, e.g. max duration/max requests) non-terminal so progression continues.
• In sweep, always run synchronous and throughput, then apply early-exit logic only during the async-rate phase.

Alternatives Considered

No response

Usage Examples

Additional Context

No response