logic and display of provider errors

[miraserver]

I can't pinpoint the exact problem. But with the last two updates, the quality of provider switching has dropped sharply. Apparently, there's a logic issue somewhere.

1. It's impossible to visually identify the specific error point. The logs always show 503, regardless of the provider's error status.
2. Switching to the next higher provider in the chain fails if they have different priorities (0, 1, 2, 3). Sometimes got error and. that's all, no connecting to next provider. Every time 503
3. There's no error log in the display chain if it's a timeout (example 30s) and again 503 error...why 503??????

[github-actions]

Thank you for reporting this issue. I've conducted a thorough analysis of the provider error handling, switching, and display logic in the codebase. Here are my findings for each of the three points you raised.

---

1. Logs always show 503 regardless of the provider's actual error status

Root cause identified: When all providers fail (after retries and switching), the forwarder throws a hardcoded 503 at src/app/v1/_lib/proxy/forwarder.ts:1255:

throw new ProxyError("所有供应商暂时不可用，请稍后重试", 503);

This means the actual upstream error status codes (e.g., 429, 500, 502, etc.) from individual providers are lost in the final response to the client. The original per-provider status codes are recorded in the internal provider decision chain (session.addProviderToChain() at lines 1169-1189), but the final error thrown to the client is always 503.

The error handler in src/app/v1/_lib/proxy/error-handler.ts:68-93 does attempt to preserve the original status code from ProxyError.statusCode, and has a fallback at line 87-93 that tries to extract the last real status code from the provider chain when the status is 500. However, this fallback only triggers for status 500, not for 503. So the hardcoded 503 from the forwarder passes through directly to the client without being replaced by the actual upstream error code.

Affected code:

• src/app/v1/_lib/proxy/forwarder.ts:1255 - hardcoded 503 throw
• src/app/v1/_lib/proxy/error-handler.ts:87-93 - fallback only checks for status 500, not 503

---

2. Switching to the next higher-priority provider fails with different priorities (0, 1, 2, 3)

Root cause identified: The provider selection logic in src/app/v1/_lib/proxy/provider-selector.ts uses selectTopPriority() (line 1029-1038) which only selects providers at the lowest (best) priority level:

private static selectTopPriority(providers: Provider[]): Provider[] {
    const minPriority = Math.min(...providers.map((p) => p.priority || 0));
    return providers.filter((p) => (p.priority || 0) === minPriority);
}

When a provider fails and the forwarder calls selectAlternative() (line 2222), it calls pickRandomProviderWithExclusion() (line 489-495), which calls pickRandomProvider() with the failed provider IDs excluded. Inside pickRandomProvider(), the flow is:

1. Filter out excluded (failed) providers
2. Filter by health/circuit breaker (filterByLimits)
3. Apply selectTopPriority() again (line 906)

The problem: if all priority-0 providers have failed and been excluded, the remaining healthy providers at priority 1, 2, 3 are available. selectTopPriority() would then correctly pick the next best priority level from the remaining healthy providers. However, the filterByLimits() step (line 957-1023) checks the circuit breaker state. If a failed provider's circuit breaker hasn't tripped yet (e.g., failure count hasn't reached the threshold), it won't be filtered out by filterByLimits, but it is excluded by the excludeIds parameter. This part should work correctly in theory.

The more likely issue is that when providers have different providerType values or different model support, the type-filtering step (around lines 667-682 and 760-810) may eliminate higher-priority providers before they can be considered as alternatives. The pickRandomProvider method filters by providerType matching the request's original format, and by model support. If your priority 1/2/3 providers have a different type or don't list the requested model in allowedModels, they would be silently excluded.

To diagnose this further, please check:

• Do all your providers (across priority levels 0-3) have the same providerType?
• Do all providers support the same models in their allowedModels configuration?
• Are the higher-priority (numerically larger) providers in the same groupTag as the lower ones?
• Check the dashboard logs for the provider decision chain - it should show filteredProviders with reasons why providers were excluded

Affected code:

• src/app/v1/_lib/proxy/provider-selector.ts:906 - selectTopPriority call during fallback selection
• src/app/v1/_lib/proxy/provider-selector.ts:760-810 - type and model filtering that may exclude valid fallback providers

---

3. No error log in the display chain for timeouts, and 503 instead of timeout-specific error

Root cause identified: Timeouts are internally represented as status code 524 (Cloudflare convention), not 503. The timeout detection is at src/app/v1/_lib/proxy/forwarder.ts:1854-1894 (response timeout) and lines 1897-1937 (streaming idle timeout). Both throw ProxyError with status 524.

The per-provider timeout errors are recorded in the decision chain with statusCode: 524 and detailed errorDetails including timeout_type and timeout_ms (lines 1169-1189). However, if the timeout causes all providers to eventually fail, the final error thrown is the same hardcoded 503 at line 1255, which overwrites the 524 timeout information.

This connects back to issue #1: the final 503 masks the actual timeout error. The client sees 503 Service Unavailable with the message "All providers temporarily unavailable" instead of a more informative 524 Timeout with details about which provider timed out and the timeout duration.

The timeout information is preserved in the database via the provider chain (providerChain field in updateMessageRequestDetails at src/app/v1/_lib/proxy/error-handler.ts:347-349), but it is not surfaced in the HTTP response to the client.

Affected code:

• src/app/v1/_lib/proxy/forwarder.ts:1871-1873 - timeout throws 524 internally
• src/app/v1/_lib/proxy/forwarder.ts:1255 - but final error is always 503
• src/app/v1/_lib/proxy/error-handler.ts:347-349 - chain is saved to DB but not in response

---

Summary

The core issue across all three points is that the final error response to the client is a generic 503 (forwarder.ts:1255) that discards the actual per-provider error details (status codes, timeout info, etc.). The detailed information exists internally in the provider decision chain but is not propagated to the client-facing error response.

A potential improvement would be to have the final error carry the last provider's actual status code and error details rather than a hardcoded 503, similar to how the error handler already attempts this for status 500 (the getLastRequestStatusCode fallback at error-handler.ts:87-93).

---

Automated response from Claude AI

[ding113]

This issue came from #754, and work is currently underway to fix it. A new version will be released soon to address this problem.