Interview Bank

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

D4 From Shot to Footage: Image-to-Video, Polling Async Tasks, and Retrying Failures

• You are asked to implement a client for an asynchronous generation task. Which failure cases would you cover?让你实现一个异步生成任务的客户端，你会考虑哪些失败情况？

  Common in ChinaCommon overseasIntermediate#async-task#error-handling

  How to reason about it · think before answering

  1. The differentiator here is coverage, not code. Answering 'wrap it in try/catch and retry' usually means you have never run this kind of API in production.
  2. Describe the shape first so the failures have somewhere to hang: submit and get an id, poll for status, retrieve a URL, download to disk — four steps, four families of failure.
  3. Then enumerate: at submit, rate limiting, auth failure, invalid parameters, content moderation; at poll, the query endpoint rate limiting you, a status that never advances, or a terminal failure; at retrieve, a valid id that yields no URL; at download, an expired link, a stream cut halfway, a disk write error.
  4. Then the two that span the whole flow: timeout and process restart. A timeout is not a failure, it is 'I don't know' — you must look up the idempotency key before resubmitting. A restart means in-memory task ids are gone, so the id has to be persisted before or immediately after the request, or you will have paid-for tasks you can never reclaim.
  5. Close with a line that shows judgment: of the four steps, only the download is safely retryable on its own; a retry at any other step can create a new billable job.
  6. Expect the follow-up: if the vendor offers callbacks, do you still poll? Yes. Callbacks get lost to restarts, network blips and unreachable endpoints, so the standard is callback-first with a low-frequency sweep for tasks stuck without a terminal state.

  分析过程 · 先想清楚再作答

  1. 这题的区分度不在代码，在你能列出多少种失败。只答「加个 try catch 和重试」的人，通常没在生产上跑过这类接口。
  2. 先把任务的形状说清楚，失败点才有地方挂：提交拿标识、轮询查状态、取件换地址、下载落盘，四步是四类不同的失败。
  3. 然后逐步列：提交阶段有限流、鉴权、参数无效、内容审核；轮询阶段有查询接口自己限流、状态一直不前进、任务返回失败终态；取件阶段有标识存在但取不到地址；下载阶段有地址过期、下到一半断流、写盘失败。
  4. 接着说横跨全程的两类：超时与进程重启。超时的关键在于它不是失败而是「不知道成没成」，必须先按幂等键查一遍再决定要不要重提；进程重启意味着内存里的任务标识没了，所以标识必须先落盘再发请求，否则你会有一批花了钱却找不回来的任务。
  5. 最后给一句能体现工程判断的话：这四步里只有下载是可以无脑重试的，其余每一步的重试都可能产生一次新的计费。
  6. 可以预期的追问：厂商提供回调了还需要轮询吗？需要。回调会因为服务重启、网络抖动、地址不可达而丢失，生产上的标准做法是回调为主、低频轮询兜底扫描长时间没有终态的任务。

  Key points

  • Break failures down by the four steps: submit (rate limit, auth, invalid params, moderation), poll (query rate limit, stalled status, terminal failure), retrieve (no URL), download (expired link, cut stream, disk error)
  • A timeout means unknown, not failed: look up the idempotency key for an existing artifact before resubmitting, or you pay twice
  • Persist the task id promptly so in-flight tasks survive a process restart
  • Only the download is safely retryable on its own; retries at the other steps can create new billable jobs
  • Keep a low-frequency polling sweep even when callbacks exist, because callbacks get lost

  答题要点

  • 按四步拆失败：提交（限流、鉴权、参数无效、内容审核）、轮询（查询限流、状态停滞、终态失败）、取件（拿不到地址）、下载（地址过期、断流、写盘失败）
  • 超时不是失败而是状态未知，重试前必须先按幂等键查一遍已有产物，否则会为同一个任务付两次钱
  • 任务标识要及时落盘，进程重启后才能把在途任务认回来
  • 四步里只有下载可以无脑重试，其余每一步的重试都可能产生新的计费
  • 有回调也要保留低频兜底轮询，回调会丢