Flux Art先保住已核实结果，再追查哪次查询晚到了
在接入 Flux Art 的业务系统里，任务先显示成功、随后又变成处理中，不应立即重建任务。先核对是否同一个 task_id、同一个业务版本，再查查询请求的发起与返回顺序。网络较慢的旧查询可能晚到，把本地显示覆盖了。本文讨论的是接入方的状态回写设计，不是声称平台会按这个顺序返回，也不是把浏览器显示直接当作远端事实。
给每次观察单独留记录
不要只保存任务表里最后一个 status 字段。为每次查询保存任务标识、业务版本、本地查询序号、请求开始时间、响应到达时间、响应状态和必要的原始依据。凭据及敏感参数不要进入普通日志。查询序号只描述本系统发起请求的顺序，不是服务端修订号；即使后发查询先回来，也不能据此断言它包含更晚的远端状态。
用一组假设响应拆开两个时间
假设查询甲先发出，查询乙后发出；乙先返回成功，甲稍后返回处理中。这不是实测结果，而是用于复现本地覆盖错误的输入。验收时应看到两条观察记录都保留，已核实成功的投影没有被旧的非终态自动降回处理中。若响应来自另一 task_id，必须先隔离身份错误，不能用下面的终态规则掩盖串任务。
| 观察情形 | 本地展示处理 | 必须保留的依据 |
|---|---|---|
| 已核实成功后到达处理中 | 不自动降级，标记旧观察 | 两次查询序号及原始响应 |
| 相同成功响应重复到达 | 保持结果，不重复入库 | 去重标识与已有文件记录 |
| 成功与失败互相冲突 | 待核对，不按状态排名选取 | 任务身份及权威复查结果 |
| 业务版本已更换 | 不覆盖新版本展示 | 请求所属版本和当前版本 |
| 响应任务标识不一致 | 隔离，不写入当前任务 | 请求与响应标识差异 |
| 查询异常没有有效状态 | 保留上次已核实信息 | 错误类型与下一次核对安排 |
观察流水与页面展示分开存
观察流水可以追加，页面展示则按明确规则更新。对同一任务已确认的终态，不让随后到达的非终态直接覆盖；把该响应记为需要解释的旧观察。如果成功、失败等终态互相冲突，不设置一个数值排名强行选赢家，而是保留冲突、核对任务身份并重新查询权威接口。结果文件已经入库，也不应因为一次显示回退就删掉。
本地并发写入必须一起受控
只有前端判断还不够。两个后端进程可能同时读到旧值，再各自写回。应在存储层用事务或条件更新，把当前任务身份、业务版本与允许的转换一起验证。检查和写入分离会留下竞态窗口。记录被拒绝的写入原因，便于区别身份不符、版本不符与终态冲突；拒绝更新展示不等于丢弃原始观察证据。
不要给接口补一个不存在的版本号
Flux Art 当前接口字段与任务查询方式应以 https://flux-art.net/zh/openapi/reference 为准。接入方新增的 observation_seq、展示版本等字段属于自建系统，不应写成平台返回值。若接口没有可比较的服务端修订号，就不能把客户端时间戳当成替代品。不同机器的时钟也可能有差异，因此时间记录主要用于排查，而不是单独决定真假。
让异常状态有明确出口
页面可以继续展示已经核实的成功结果，同时把冲突标记交给运营或技术处理；尚未核实的冲突则显示待核对，不伪装成已解决。重新查询也要有次数和间隔上限，遇到限流遵守响应要求。用户刷新页面只读本地投影，不应自动触发新的创建请求。查询失联、创建结果未知和已确认失败是三件不同的事。
复现测试要包含迟到、重复和串号
至少安排旧非终态晚到、相同响应重复到达、两个终态冲突、业务版本更换、错误任务标识以及两个写入者同时提交六类输入。每次检查观察数量、展示状态、结果文件和是否误发创建请求。测试应使用隔离记录，不把模拟成功写进真实任务台账。通过标准不仅是页面好看，还包括没有重建任务、没有丢掉异常依据。
把接入与素材生产各自交付
使用 https://flux-art.net/zh 进行素材制作时，业务团队仍要验收图片内容；状态成功不能替代素材质量审核。开发交付的是观察字段说明、状态转换规则、并发写入测试与异常队列。运营交付的是当前任务对应的批准素材。两份记录通过 task_id 和业务版本关联，才能分清网络回写问题与实际交付问题，避免用重新出图掩盖系统错误。