What causes "HTTP error! status: ${response.status}" in yikart/AiToEarn?

Log response.status and read response.text() before throwing to capture the server's error detail.

yikart/AiToEarn · error · Error

HTTP error! status: ${response.status}

Error message

HTTP error! status: ${response.status}

What it means

thrown by aiChatStream's fetch wrapper when the HTTP response is not ok. It is a minimal non-ok guard that surfaces only the numeric status, discarding the response body which likely contains the real error JSON.

Source

Thrown at project/aitoearn-web/src/api/ai/ai.api.ts:437

    headers: {
      'Content-Type': 'application/json',
      'Authorization': token ? `Bearer ${token}` : '',
      'Accept-Language': lang || 'en',
    },
    body: JSON.stringify({
      stream: false, // 使用非流式响应
      model: 'gpt-5.1-all',
      temperature: 1,
      presence_penalty: 0,
      frequency_penalty: 0,
      top_p: 1,
      max_tokens: 8000, // 增加到8000以支持更长的响应（包括base64图片）
      ...data,
    }),
  })

  if (!response.ok) {
    throw new Error(`HTTP error! status: ${response.status}`)
  }

  return response
}

/**
 * 获取 Agent 生成的素材列表
 * @param params - 分页参数
 * @param params.page - 页码
 * @param params.pageSize - 每页数量
 * @returns 素材列表
 */
export function getAgentAssets(params?: AiPaginationParams) {
  return http.get<AssetListVo>('ai/assets', params)
}

/** 创建 AI 批量生成草稿任务 */
export function apiCreateDraftGeneration(data: CreateVideoDraftGenerationParams) {

View on GitHub (pinned to d3aa8bea5b)

Solutions

Log response.status and read response.text() before throwing to capture the server's error detail.
Handle 429 with backoff retry, 401 with token refresh, 4xx with payload validation.
Verify the request body (model, max_tokens, messages) against the current provider/backend contract.
Check backend health if 5xx statuses recur.

Example fix

// before
if (!response.ok) {
  throw new Error(`HTTP error! status: ${response.status}`)
}
// after
if (!response.ok) {
  const detail = await response.text().catch(() => '')
  throw new Error(`HTTP error! status: ${response.status} body: ${detail}`)
}

Defensive patterns

Strategy: try-catch

Validate before calling

// validate request before fetch
if (!data.model) throw new Error('model is required')
if (!Array.isArray(data.messages) || data.messages.length === 0) throw new Error('messages required')

Type guard

function isHttpError(e: unknown): e is Error & { status?: number } {
  if (!(e instanceof Error)) return false
  const m = /status: (\d{3})/.exec(e.message)
  ;(e as any).status = m ? Number(m[1]) : undefined
  return true
}

Try / catch

try {
  const resp = await aiChatStream(payload)
}
catch (e) {
  const status = /status: (\d{3})/.exec(e instanceof Error ? e.message : '')?.[1]
  if (status === '429') await backoffAndRetry()
  else if (status === '401') await refreshTokenAndRetry()
  else showError(e)
}

Prevention

Always check response.ok and read the error body for diagnostics before throwing.
Handle 429 with retry-after backoff, not immediate failure.
Keep max_tokens and model names within the provider's current limits.
Centralize fetch error handling so status-specific logic lives in one place.

When it happens

Trigger: POSTing the chat completion request when the AI backend returns a non-2xx status: 401 bad/expired key, 400 invalid params, 429 rate limit, 5xx backend failure — any case where response.ok is false.

Common situations: max_tokens or payload exceeding provider limits; model name no longer supported; API key rotated on the server; rate limiting during bursts.

Related errors

AI-assisted analysis of yikart/AiToEarn@d3aa8bea5b (2026-08-31). Data as JSON: /api/errors/e950f6202304c2a1. Report an issue: GitHub.