Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D11 The Run State Machine, Streaming Output Back, Ordering by runId, SSE Waiters, Merging Interruptions Within 30 Seconds

• After a streaming client reconnects, how do you deliver every missed chunk exactly once — no gaps, no duplicates?流式接口的客户端断线重连后，怎么做到既不丢片段也不重复？

  Common in ChinaCommon overseasDeep dive#sse#idempotency#reconnect

  How to reason about it · think before answering

  1. Answer 'no gaps' and 'no duplicates' separately. Plenty of candidates cover only the first — they backfill from storage but never say how the overlap is deduplicated.
  2. The chain is short: the client knows the last id it received, it sends that id back on reconnect, the server resumes from the next one — and all of that requires contiguous, monotonic numbering. Whether resumption is possible at all was decided when you chose the sequence scheme; timestamps or random ids break the chain at step one.
  3. Then the three steps and their individual traps. Convert: the client reports the last id it *received*, so add one — off by minus one repeats a frame, off by plus one drops a character, and this is the only arithmetic in the whole flow and the most commonly wrong line. Replay: read the missing range from durable storage, which is always complete. Attach: resume the live stream, whose overlap with the replay is guaranteed, and drop anything below the cursor. That single comparison is all there is to idempotent replay.
  4. Explain why the dual write is mandatory: chunks go both to the stream and to the table. Stream only, and the early chunks are gone by reconnect time; table only, and you are polling the database, pushing time-to-first-token from tens to hundreds of milliseconds. The cost is write amplification — hundreds of rows per answer — so production batches the writes, every few dozen chunks or every couple hundred milliseconds.
  5. Get the protocol detail right: the browser's native event source replays the last id in a request header for you, but model endpoints generally need POST while that API only issues GET, so real frontends hand-roll the parser and must resend the id themselves. Mentioning this proves you have actually wired up the client side.
  6. Expect: how long do you keep replayable data? Give two bounds — a retention window (per-chunk rows only for runs from the last few hours, then collapsed into one complete message) and a replay cap (beyond N chunks, send the full text once instead of re-enacting it character by character). Without both, that table becomes the largest in the database while 99% of its rows are never read again after ten seconds.

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

  1. 「不丢」和「不重复」要分开答。只答一半的人很多：说了从库里补发（不丢），却没说重叠部分怎么去重（不重复）。
  2. 推导链很短：客户端知道自己最后收到的编号 → 它重连时把这个编号带回来 → 服务端从下一号开始给 → 前提是编号连续不跳号。所以能不能重连，取决于当初有没有把序号设计成从 0 开始、连续、单调。序号一旦是时间戳或随机 id，这条链第一步就断了。
  3. 然后给三步实现和各自的坑：第一步换算，带回来的是「最后收到」的那一号，要加一，少加一重复一帧、多加一丢一个字，这是整段逻辑里唯一的算术也最常写错；第二步先从持久化里回放缺的部分，因为库里一定是全的；第三步再接上还在流动的那条流，两边必然重叠，靠「小于当前指针的一律丢弃」去重——幂等回放的全部秘密就是这一次比较。
  4. 这里要点出为什么必须双写：片段既进流也进库。只有流，重连时早期片段已被消费掉；只有库，就得轮询查库，首字延迟从几十毫秒涨到几百毫秒。代价是写放大，一次回答几百个片段就是几百行，生产里按批落库（每几十个片段或每两百毫秒一次）。
  5. 对齐一下协议细节：浏览器原生的事件源会自动把上次的编号放进重连请求头带回来；但大模型接口通常要用 POST，原生事件源只能发 GET，所以真实前端多是手写解析，重连时要自己把编号带上——这个细节能证明你真接过前端。
  6. 可以预期的追问：回放要保留多久？必须给两个边界——保留期（逐片段的行只对最近若干小时的执行保留，之后归档成一整条完整回复并删掉碎行）和回放上限（一次重连最多回放多少片段，超了就一次性发完整文本而不是逐字重演）。不定这两条，那张表会变成全库最大且 99% 的行写完十秒后再没人读。

  Key points

  • Resumption requires a contiguous, monotonic sequence starting at 0; timestamps or random ids make it impossible
  • The client reports its last received id, so the server resumes from that id plus one — the single most error-prone line
  • Replay the gap from durable storage first, then attach the live stream, discarding anything below the cursor to dedupe the overlap
  • Dual-write every chunk: the stream serves currently attached connections, the table serves clients that come back later; batch the writes in production
  • Set a retention window and a replay cap — archive old runs into one complete message and send full text instead of re-enacting long replays

  答题要点

  • 重连的前提是序号从 0 开始、连续、单调；序号是时间戳或随机 id 就无法续传
  • 客户端带回来的是「最后收到」的那一号，服务端要加一再开始，这是唯一的算术也最容易错
  • 先从库里回放缺的片段（库一定是全的），再接上还在流动的流，重叠部分靠「小于当前指针一律丢弃」去重
  • 片段必须双写：流服务当前挂着的连接，库服务等一下才回来的人；代价是写放大，生产里按批落库
  • 必须定保留期与回放上限：过期的执行归档成一整条完整回复，超长回放直接一次性发完整文本