Files
Genarrative/docs/technical
lhk229 cc88564d4a
Project CI / Repository checks (pull_request) Failing after 47s
Project CI / Frontend tests (pull_request) Successful in 2m53s
Project CI / Backend tests (pull_request) Successful in 3m32s
Project CI / Native shell tests (pull_request) Failing after 7m31s
完美像素未知结果先对账再定性
catch 此前对所有错误一视同仁:标 failed、finally 解锁、按钮恢复可点。transport
异常、abort 和 120 秒客户端超时因此被谎报成明确失败,而服务端此时很可能已经完成
OSS PUT、asset object、project resource、账号素材和画布回填,只是响应没回来。用户
按提示重试就再造一整份。这违反本功能自己立下的契约:结果未知时先 GET 权威快照,
由用户显式决定是否再次执行。

判别依据是 ApiClientError 只在拿到 Response 时由 buildApiClientError 构造,
transport 异常、AbortError 和 TimeoutError 在重试判定后原样抛出。已知结果不发
对账 GET,避免每个 400 都多打一次权威读取。

未知结果先 loadEditorProject,再按占位是否存活分流:占位已被 completion 消费掉
说明这次其实成功,按快照收口并写入正常的 perfect-pixel 历史;占位仍在说明画布没
收到结果,同步快照但不写历史,文案要求先核对素材库再决定是否重试——持久化是非
事务的,对象和素材可能已落库而画布回填未完成。对账 GET 本身失败时给独立文案,
不退回谎报。

既有用例 keeps a failed perfect-pixel placeholder 原本用裸 Error 表达「服务端识别
不到网格」,语义不准且会误入对账路径,改为 ApiClientError。harness 新增
dialog-error 输出,否则对账文案不可观测。

刷新后停在 generating 的占位仍无自动收口,需要先给 dialog 增加「无 durable job 的
inline 链路」标记才能在 hydration 后对账,改动面大于本次,单独立项。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 11:44:57 +00:00
..