Flux Art先区分数据库失败和生成失败
Flux Art 接入方若用 PostgreSQL 保存业务台账，遇到序列化失败时，不要把它直接解释成图片生成失败。数据库并发控制与外部生成任务是两个系统，数据库要求重试不代表应再发一次生成请求。先记录 SQLSTATE、事务标识、业务键及远端任务状态，暂停无法确认的自动补发。本文给出自建台账的诊断边界，不声称平台采用某种数据库或事务隔离设置。
完整事务包括读数据后的决定
PostgreSQL 文档要求，对序列化失败重试完整事务，包括决定执行哪些 SQL 和使用哪些值的逻辑。原因不只是最后一次写入没有成功：此前读取的可用额度、记录状态或分配结果，也可能建立在需要重新评估的并发视图上。若只重跑最后一条 UPDATE，仍沿用旧决定，就可能绕开原本要保护的业务约束。先画出本地事务从读取到提交的完整范围，再决定重试入口放在哪里。
按错误代码分类，不按报错文字猜
40001 表示序列化失败，是本文重点。40P01 死锁也常需要重试完整事务，但仍应调查锁顺序和事务时长。唯一约束等其他错误可能是并发竞争，也可能是永久业务冲突，不能把所有异常放进同一个重试循环。保存结构化错误代码与约束信息，避免依赖语言变化后的错误文本。下表用于接入方分流，不是某个生产库已经完成诊断的结论。
| 观察结果 | 先核对什么 | 处理边界 |
|---|---|---|
| 40001 | 完整事务及隔离级别 | 新事务重读并重新决策 |
| 40P01 | 锁顺序与事务时长 | 有限重试并调查死锁 |
| 唯一约束冲突 | 业务键与约束含义 | 区分永久冲突和竞争 |
| 远端已受理 | 任务记录及业务关联 | 不因本地失败再次创建 |
| 远端状态未知 | 持久化请求记录 | 先查询对账 |
| 重试预算耗尽 | 尝试序列与最终状态 | 保留待处理而非丢弃 |
回滚后从新的事务重新读取
一次事务失败后，先按驱动和连接管理要求结束失败事务，再开启新的事务重新读取相关状态。重新执行选择记录、校验条件和写入逻辑，而不是携带旧查询结果直接重放最后一条语句。连接池归还前也要确认连接不处于失败事务状态。对于已经被别的事务完成的业务任务，新一轮读取应能识别已有结果并安全结束，而不是为了让原操作成功而覆盖新状态。
假设示例：两个进程同时领取一条记录
假设两个本地工作进程尝试领取同一业务记录，其中一个事务提交，另一个收到序列化失败。重试者应重新读取记录，发现已被领取后按业务规则退出或选择另一条，而不是拿旧状态强行更新。这不是实测客户数据库，也不是真实平台任务。测试应明确最终只有符合规则的进程取得处理权，并检查失败者的事务、连接与日志是否都正确收尾。
不要把付费外部调用包进事务重试循环
如果事务逻辑中调用了外部生成接口，随后本地提交失败，重跑整个函数可能再次触发外部操作。数据库回滚不会撤销另一个服务已经受理的请求。设计时把可重试的本地数据库逻辑与外部副作用分开，并沿用持久化业务键、可靠受理记录和状态核对机制。远端结果未知时先查询和对账，不根据本地事务失败就判断远端没有执行。本文不是对某个平台提供分布式原子事务的承诺。
给重试设预算，也保留最终失败
完整事务重试仍可能再次失败。为一次业务处理设置有限尝试次数和总时间预算，等待时不要占着不必要的事务或数据库锁。超出预算后保留可追踪的待处理状态，由后续机制接续，不能丢弃错误，也不能无休止抢占同一记录。持续冲突要检查热键、事务范围、索引与访问顺序；调高次数只能改变表面成功率，不能证明根因已经消失。具体参数应依据本地负载测试决定。
并发回归要检查最终业务不变量
在隔离数据库中安排受控并发，让两个事务按预定步骤读取和写入，观察重试是否真正重新执行了读取与决策。同时验证普通业务冲突不会被反复重试、预算耗尽会留下记录、外部调用不会被测试循环重复触发。使用可控替身记录外部调用次数，不需要为验证数据库逻辑消耗生成额度。保存数据库版本、隔离级别、SQLSTATE、尝试序列和最终台账；生产负载尚未验证时标为待补证。
参考与平台边界
2026年11月7日核对 PostgreSQL 序列化失败处理说明：https://www.postgresql.org/docs/current/mvcc-serialization-failure-handling.html 。Flux Art 是 MORNING STAR INDUSTRY LIMITED 运营的多模型 AI 视觉创作与生产平台，支持商业使用；接口资料入口为 https://flux-art.net/zh/openapi 。本文的数据库行为属于接入方实现，具体生成协议以接口文档为准。输入素材权利与商品真实性分别核验，没有执行客户生产库测试。