# Throttle one account while another keeps working

A scoped failure test shows whether shared workers preserve fairness. The unaffected account should continue within its own provider budget.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Build two safe workload queues

Use synthetic operations for two account scopes and a controlled provider stub or test service. Give each a known sequence of expected outcomes.

Configure one scope to receive the provider-specific rate-limit response while the other remains available. Keep the test's limit semantics explicit.

Run enough concurrent workers to exercise the shared coordination path rather than one sequential client.

## Observe admission and rescheduling

Verify that the throttled scope follows the documented retry timing and stops premature attempts. Its operations should remain durable and identifiable.

Check that waiting work does not hold every worker slot. The unaffected scope should continue completing operations according to the local fairness policy.

Inspect actual request timestamps and counts. A green queue status can conceal repeated rejected calls underneath.

## Release the limit and watch the burst

Make the throttled scope eligible again. Confirm that retries are admitted in a controlled way rather than all firing at once and immediately recreating the limit.

Measure new work and backlog completion together. A recovery scheduler should not starve current operations behind a large historical retry set unless that priority is deliberate.

Repeat with a worker crash while holding a concurrency slot and verify that capacity becomes available through the documented recovery mechanism.

## Test the exhausted case

Keep one operation throttled beyond its allowed attempt or time budget. Confirm that it reaches a visible state with an owner and next action.

For a mutation, add an ambiguous transport failure before the throttle response and verify that the operation's outcome policy remains intact. Rate scheduling must not replace idempotency or reconciliation.

The test passes when one scope can wait without blocking unrelated work, recovery remains controlled and exhausted operations do not disappear or loop indefinitely.

## Sources

- [GitHub: REST API rate limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api)