Client or integration
Direct HTTP/API client
Area
Proxy and routing
Summary
waitForProviderRequestSlot throws RequestPacingQueueOverloadError when a provider's request-pacing queue is full. The runTurn path in src/server/responses/core.ts (around line 3247) translates that error into a retryable 429 rate_limit_error event, but the generic transport catches around the initial fetchResponse dispatch (around lines 3451-3480) and rebuildAndRefetch (around lines 3544-3565) convert every error into 502 upstream_error. Under pacing-queue pressure, requests dispatched through those paths receive a 502 instead of the retryable-429 contract used elsewhere for the same condition.
Additionally, noteAttemptSend runs before waitForProviderRequestSlot admits the request on the fetchResponse branch (around line 3457), so overload-rejected requests still inflate the attempt send count.
Reproduction
Found by code review while working on #1743; not yet reproduced at runtime. Code-path walkthrough against dev @ 4b950101a1116d8bac4e479cb2dceca3bb80370e:
- Configure a provider with request pacing where the queue capacity is small relative to the burst.
- Send a burst of
/v1/responses requests routed through a provider adapter that uses fetchResponse, or trigger the rebuild/refetch retry path.
- When the pacing queue is full,
waitForProviderRequestSlot throws RequestPacingQueueOverloadError (src/server/responses/core.ts:3451 or :3545).
- The surrounding catch converts it to
502 upstream_error (lines ~3473-3480 / ~3560-3565) instead of the retryable 429 shape the runTurn path produces at ~3247.
Expected: the same retryable-429 mapping as the runTurn path, with noteAttemptSend moved after successful pacing admission so rejected requests do not count as sends.
Version
dev @ 4b950101a1116d8bac4e479cb2dceca3bb80370e (pre-existing path; unchanged by #1743)
Operating system
Linux (Debian 13); the code path is platform-independent
Provider and model
Any forward-auth Responses provider with request pacing configured
Logs or error output
No response
Screenshots and supporting files
No response
Redacted configuration
No response
Checks
Client or integration
Direct HTTP/API client
Area
Proxy and routing
Summary
waitForProviderRequestSlotthrowsRequestPacingQueueOverloadErrorwhen a provider's request-pacing queue is full. TherunTurnpath insrc/server/responses/core.ts(around line 3247) translates that error into a retryable 429rate_limit_errorevent, but the generic transport catches around the initialfetchResponsedispatch (around lines 3451-3480) andrebuildAndRefetch(around lines 3544-3565) convert every error into502 upstream_error. Under pacing-queue pressure, requests dispatched through those paths receive a 502 instead of the retryable-429 contract used elsewhere for the same condition.Additionally,
noteAttemptSendruns beforewaitForProviderRequestSlotadmits the request on thefetchResponsebranch (around line 3457), so overload-rejected requests still inflate the attempt send count.Reproduction
Found by code review while working on #1743; not yet reproduced at runtime. Code-path walkthrough against
dev@4b950101a1116d8bac4e479cb2dceca3bb80370e:/v1/responsesrequests routed through a provider adapter that usesfetchResponse, or trigger the rebuild/refetch retry path.waitForProviderRequestSlotthrowsRequestPacingQueueOverloadError(src/server/responses/core.ts:3451or:3545).502 upstream_error(lines ~3473-3480 / ~3560-3565) instead of the retryable 429 shape therunTurnpath produces at ~3247.Expected: the same retryable-429 mapping as the
runTurnpath, withnoteAttemptSendmoved after successful pacing admission so rejected requests do not count as sends.Version
dev@4b950101a1116d8bac4e479cb2dceca3bb80370e(pre-existing path; unchanged by #1743)Operating system
Linux (Debian 13); the code path is platform-independent
Provider and model
Any forward-auth Responses provider with request pacing configured
Logs or error output
No response
Screenshots and supporting files
No response
Redacted configuration
No response
Checks