北京
“准备中… 0/0。” 用户点击“提问本书”，屏幕上就冒出这行字。它看着像是进度条刚刚启动，但对于某些书来说，这行字就是终点——进度永远不会再跳一下，重试按钮也无济于事。整个功能就这样无声地死在这里，唯一的解药是开发者手动去数据库里捅一刀。
问题藏在一个极易被忽略的设计里：索引工作被直接塞进了 HTTP 请求。用户点击触发时，服务端先闪电般把 rag_status 改成“索引中”，然后开始啃那本 PDF——切分成文本块，再一页页调付费视觉解析，整套流程能跑上好几十分钟。Cloudflare 才不会等你那么久，早早把请求掐断；容器每次重启部署也会让正在干活儿的进程直接蒸发。于是数据库里就留下这样一行：rag_status = Indexing，rag_chunk_count = 0，一个看似正在运转、实则已经死透的状态。
真正的致命一击在重试路径里。旧代码在接手新索引任务时，只认状态为“未索引”或“失败”的行。那行卡在“索引中”的记录，既不算失败也不算出活儿，永远轮不到第二次机会。一个没有出口的状态机就这样诞生了：进度条永远停在 0/0，没有错误提示，也没有自动恢复的路径。
修复的思路干脆利落：端点只负责拍板决策，真正干体力活的全部交给幕后 worker。新的请求一进来，端点立刻返回 202，把 rag_status 翻到“索引中”就拍拍手走人——HTTP 路径上不跑任何付费任务，再也不怕 Cloudflare 中途断连。与此同时，一个 worker 用一条原子化的 UPDATE 语句去抢活儿：WHERE rag_status = 1 AND rag_chunk_count = 0 AND rag_indexing_started_at IS NULL。PostgreSQL 当裁判，两个 worker 撞上同一行，只有一个拿到 1 行更新计数，继续干活儿，另一个灰溜溜返回。最后再补一道清扫逻辑，把那些真的死掉的行重新回收给健康 worker。
开发者把整段经历捅进 DEV 的夏日除虫挑战，顺便把修复详情和代码全晾在 TextStack 的公开仓库里。对于碰过进度条卡死、后台任务超时这类暗坑的工程师来说，这是一个教科书式的微型复盘：状态机再小，也得给每个节点留个出口。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
