Pool mode currently retries the same account for a fixed set of
upstream HTTP statuses: 401, 403, 429. Some upstream pool deployments
also need same-account retry for transient provider/proxy statuses
such as 502, 503, 520, 529, but hard-coding more statuses changes
behavior for everyone.
Add a per-account credentials option `pool_mode_retry_status_codes`
that lets admins choose which upstream HTTP status codes trigger
same-account retry in pool mode:
- Unset (default): preserve the current 401/403/429 default
- Explicit list: override the defaults with the configured codes
- Codes normalized to the 100-599 range, deduplicated, sorted
The standalone `isPoolModeRetryableStatus` helper is kept as the
default-only fallback. All 15 gateway call sites switch to the new
`Account.IsPoolModeRetryableStatus` method so behavior is preserved
for accounts that do not configure the new field.
Frontend admin UI gains a "Retry Status Codes" comma-separated input
under the pool-mode section in both Create/Edit account modals
(en + zh i18n).
Fixes#2731
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Image generation requests (forwardOpenAIImagesOAuth and
forwardOpenAIImagesAPIKey) were calling detachStreamUpstreamContext with
parsed.Stream, which for non-streaming requests (Stream=false) simply
returned the original client context unchanged. When the client
disconnected before the upstream completed (30-80s for image gen), the
context cancellation propagated to the upstream HTTP request, causing a
502 error despite the upstream having already started processing.
Switch to detachUpstreamContext (unconditional detach) so the upstream
image generation request is always bound to a background context and
completes regardless of client lifecycle.
Fixes#2310
