Bug Description
AI translation fails consistently with HTTP 502 from the configured OpenAI-compatible provider, then falls back to Google Translate which returns 429. The AI Profile connection test passes, but actual translation requests fail.
Environment
- OS: Windows 11
- MrRSS Version: 1.3.28 (desktop release)
- Installation Method: official release installer
Steps To Reproduce
- Create an AI Profile pointing to an OpenAI-compatible chat completions endpoint (custom gateway, not api.openai.com).
- Run the profile connection test (
POST /api/ai/profiles/{id}/test) → passes: connection_success: true, model_available: true, ~2-5s response.
- Set
translation_provider=ai and ai_translation_profile_id to that profile.
- Call
POST /api/articles/translate-text with an English text and target_language=zh-CN.
- Observe failure: log shows
AI translation failed code=request_failed status=502; using Google Translate fallback, then Error translating text: translation api returned status: 429.
Key Observation (mechanism-level)
The same endpoint, same API key, and an equivalent request body (model, messages with system+user prompts, temperature 0.3, max_tokens 2048, stream:false) succeed with HTTP 200 when issued externally (curl, Python urllib, httpx — both HTTP/1.1 and HTTP/2). Only the in-process MrRSS request gets 502.
This suggests the failure is not about the provider or the payload, but about how the translation path constructs its HTTP client vs. how the profile test path does:
- Profile test (
testAIProfileConnection in internal/handlers/ai/ai_profiles_handlers.go) uses a plain &http.Client{} (default transport, HTTP/2 negotiation).
- Translation path (
AITranslator → ai.NewClient → httputil.CreateHTTPClient in internal/utils/httputil/httputil.go) uses a transport with ForceAttemptHTTP2: false and an explicit TLSClientConfig (MinVersion TLS1.2, InsecureSkipVerify from env).
Hypothesis: the explicit TLSClientConfig changes the Go TLS ClientHello fingerprint, and some OpenAI-compatible gateways (especially those behind WAF/anti-bot layers) reject that fingerprint with 502. The default transport (used by the passing profile test) negotiates differently and is accepted.
Expected Behavior
- Translation requests should use the same HTTP client construction as the profile test path (which demonstrably works), or
- The HTTP client should be configurable (custom headers / User-Agent / HTTP version) per profile so gateway-specific quirks can be worked around.
Additional Notes
Bug Description
AI translation fails consistently with HTTP 502 from the configured OpenAI-compatible provider, then falls back to Google Translate which returns 429. The AI Profile connection test passes, but actual translation requests fail.
Environment
Steps To Reproduce
POST /api/ai/profiles/{id}/test) → passes:connection_success: true,model_available: true, ~2-5s response.translation_provider=aiandai_translation_profile_idto that profile.POST /api/articles/translate-textwith an English text andtarget_language=zh-CN.AI translation failed code=request_failed status=502; using Google Translate fallback, thenError translating text: translation api returned status: 429.Key Observation (mechanism-level)
The same endpoint, same API key, and an equivalent request body (model, messages with system+user prompts, temperature 0.3, max_tokens 2048, stream:false) succeed with HTTP 200 when issued externally (curl, Python urllib, httpx — both HTTP/1.1 and HTTP/2). Only the in-process MrRSS request gets 502.
This suggests the failure is not about the provider or the payload, but about how the translation path constructs its HTTP client vs. how the profile test path does:
testAIProfileConnectionininternal/handlers/ai/ai_profiles_handlers.go) uses a plain&http.Client{}(default transport, HTTP/2 negotiation).AITranslator→ai.NewClient→httputil.CreateHTTPClientininternal/utils/httputil/httputil.go) uses a transport withForceAttemptHTTP2: falseand an explicitTLSClientConfig(MinVersion TLS1.2, InsecureSkipVerify from env).Hypothesis: the explicit
TLSClientConfigchanges the Go TLS ClientHello fingerprint, and some OpenAI-compatible gateways (especially those behind WAF/anti-bot layers) reject that fingerprint with 502. The default transport (used by the passing profile test) negotiates differently and is accepted.Expected Behavior
Additional Notes
translate.googleapis.com/translate_a/single?client=gtx) is rate-limited (429) in this environment — related to [FEATURE] Switch to a new Google Translate endpoint #158.