jlcodes99/cockpit-tools · error
网关 {} 返回错误: status={}, body_len={}
Error message
网关 {} 返回错误: status={}, body_len={} What it means
post_gateway_json received an HTTP response but with an error status; it logs details (url, status, body length, truncated body) and returns '网关 {op} 返回错误: status={}, body_len={}'. The gateway answered, but the operation failed server-side (4xx client error or 5xx server error).
Source
Thrown at src-tauri/src/modules/wakeup.rs:767
crate::modules::logger::log_error(&format!("[Wakeup] {}", message));
message
})?;
let status = resp.status();
let text = await_with_cancel(cancel_rx, resp.text())
.await?
.unwrap_or_default();
if !status.is_success() {
crate::modules::logger::log_error(&format!(
"[Wakeup] 网关 {} 返回错误: url={}, status={}, body_len={}, body={}",
op_name,
url,
status,
summarize_body_len(&text),
truncate_log_text(&text, 512)
));
return Err(format!(
"网关 {} 返回错误: status={}, body_len={}",
op_name,
status,
summarize_body_len(&text)
));
}
serde_json::from_str::<serde_json::Value>(&text).map_err(|e| {
let message = format!("网关 {} 响应解析失败: {} (url={})", op_name, e, url);
crate::modules::logger::log_error(&format!(
"[Wakeup] {},body_len={}",
message,
summarize_body_len(&text)
));
message
})
}
async fn resolve_requested_model_for_official_ls(View on GitHub (pinned to 1ed8b77992)
Solutions
- Check `status` in the message: 4xx → fix request/auth; 5xx → server-side, retry later
- Inspect the truncated body in logs for the gateway's error detail
- Refresh gateway credentials/session if 401/403
- Back off and retry on 429/5xx (the code marks retryable = 429 or >=500)
- Compare request payload against the gateway API version — update the client if schema drifted
Example fix
// before
return Err(format!("网关 {} 返回错误: status={}, body_len={}", op_name, status, summarize_body_len(&text)));
// after
let retryable = status == reqwest::StatusCode::TOO_MANY_REQUESTS || status.as_u16() >= 500;
return Err(format!("网关 {} 返回错误: status={}, retryable={}, body_len={}",
op_name, status, retryable, summarize_body_len(&text))); Defensive patterns
Strategy: retry
Validate before calling
// Validate payload shape and auth before calling the gateway op
fn precheck(payload: &serde_json::Value, token: &str) -> Result<(), String> {
if token.is_empty() { return Err("missing gateway session token".into()); }
if payload.get("op").is_none() { return Err("payload missing 'op'".into()); }
Ok(())
} Type guard
fn is_gateway_http_error(err: &str) -> bool { err.contains("返回错误: status=") } Try / catch
let retryable = |e: &str| e.contains("status=429") || {
e.split("status=").nth(1).and_then(|s| s.split(',').next())
.and_then(|s| s.parse::<u16>().ok()).map_or(false, |c| c >= 500)
};
match post_gateway_json(...).await {
Err(e) if is_gateway_http_error(&e) && retryable(&e) => retry_with_backoff().await,
Err(e) if is_gateway_http_error(&e) => eprintln!("non-retryable gateway error: {}", e),
other => handle(other),
} Prevention
- Retry only on 429/5xx with exponential backoff and jitter
- Log the truncated response body (as the code does) for every non-2xx
- Keep request payloads aligned with the gateway API version; add schema tests
- Refresh gateway credentials when 401/403 appears
When it happens
Trigger: trigger_wakeup_via_client_gateway_once → post_gateway_json gets status outside 2xx, e.g. 400 from a malformed request payload, 401/403 auth failure at the gateway, 429 rate limiting, or 5xx gateway crash/overload.
Common situations: Expired gateway session/token; request schema changed after a gateway version update; payload exceeding limits; 429 rate limiting under heavy wakeup traffic; gateway deployment broken (5xx).
Related errors
- 网关 {} 请求失败[{}]: {} (url={})
- 网关 {} 响应解析失败: {} (url={})
- 网关 prepareStartContext 请求失败[{}]: {} (url={})
- 网关未在超时时间内返回唤醒结果,最后状态={}
- Claude OAuth start 响应缺少关键字段
AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05).
Data as JSON: /api/errors/344f917ef3444751.
Report an issue: GitHub.