P76 · Tool use

Staggered Burst Query + Rate Limits

Limit concurrent queries and apply service-specific backoff.

Editorially reviewedSource unconfirmed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Read metadata from independent services. Teaching limits are A=2 concurrent/B=1; A429 has Retry-After 3seconds and B may 403. One failure should not erase unrelated success without a dependency reason.

Mechanism

Enforce current per-service concurrency and bounded stagger/backoff. Honor supported Retry-After and overall budget; authentication errors follow contracts without storms. Collect independent success/failure/pending states; global cancellation needs a real shared prerequisite.

Bad example

Fire all requests, retry every error indefinitely and cancel/discard A on B403 while claiming complete output.

Good example

Apply teaching A2/B1 limits with request identities. A429 waits 3seconds for at most one agreed retry; budget expiry remains unfinished. B403 reports access gap without blind retries. Collect each independently and retain actual statuses without fabricated data/completeness.

Why the change matters

Concurrency/backoff bound rejected traffic; independent collection preserves useful evidence. Error semantics/dependencies decide recovery rather than one universal status-code action.

Observable expectation

Trace A≤2/B≤1, proper 429 spacing and bounded retry. A success/B403 yields A plus B gap.

Inspect cancellation/budget contract instead of any 403 as global failure; no real bursts run.

Limits

Retry-After formats/absence need actual protocol handling. Numbers/retry count are teaching choices. Write retries also need idempotency, and cross-service cancellation depends on runtime/shared prerequisites.

Sources and evidence

Source text has not been located. This method meets the editorial criteria; its examples are independent teaching constructions.

Read the editorial criteria

Related methods