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
..
2026-08-01 11:44:57 +00:00
2026-08-01 18:33:10 +08:00
2026-07-20 16:08:24 +08:00
2026-06-16 16:06:54 +08:00
2026-07-31 09:11:12 +00:00
2026-07-23 13:47:32 +08:00
2026-07-14 11:11:11 +08:00