Skip to content

Streaming Concurrency Limit

URI: https://docs.ankatech.co/errors/streaming-concurrency-limit
HTTP Status: 429 Too Many Requests

When you see this

Too many true-streaming requests were already in flight when this one arrived. Two bounds are enforced independently: a global bound protecting the instance's thread pools, and a per-tenant bound so one tenant cannot consume the whole global allowance. The service is healthy and the request is well formed — what is exhausted is the allowance, which is why this is a 429 and not a 503. The response carries Retry-After: 5; an admitted request runs and a refused one is answered immediately, because queueing would hold the very thread the bound exists to protect.

Common Causes

  • More concurrent streaming uploads than the global bound admits on this instance.
  • One tenant running more concurrent streaming operations than the per-tenant bound admits, while the instance as a whole still has capacity.
  • Long-lived streaming requests holding their slot: the permit is held across the whole asynchronous cycle, not released when the request thread unwinds.

The two bounds are configurable, and the detail states both values as this instance is configured:

  • ankasecure.streaming.max-concurrent-requests (environment variable ANKASECURE_STREAMING_MAX_CONCURRENT_REQUESTS, default 32) — the global bound.
  • ankasecure.streaming.max-concurrent-requests-per-tenant (environment variable ANKASECURE_STREAMING_MAX_CONCURRENT_REQUESTS_PER_TENANT, default 8) — the per-tenant bound.

Response Example

{
  "type": "https://docs.ankatech.co/errors/streaming-concurrency-limit",
  "title": "Too Many Concurrent Streaming Requests",
  "status": 429,
  "detail": "Too many concurrent streaming requests. At most 32 may be in flight on this instance and at most 8 for any one tenant. Retry shortly.",
  "instance": "/api/v3/migration/stream/analyze-pkcs7",
  "correlationId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "timestamp": 1730000000
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Retry after the delay the Retry-After header names. Occupancy frees as in-flight streams complete.
  2. Reduce client-side concurrency so it stays under the per-tenant bound the detail states.
  3. If the workload legitimately needs more capacity, raise ankasecure.streaming.max-concurrent-requests and ankasecure.streaming.max-concurrent-requests-per-tenant together. The per-tenant bound must not exceed the global one — the filter refuses to start otherwise, because a per-tenant bound above the global one can never be reached.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.