Repository navigation
[BUG] 显式上传派发丢掉平台的稳定分类码 —— #918 修好的那一类的第二个实例 #940
Description
Activity
- added a commit that references this issue
on Aug 13, 2026 - added a commit that references this issue
on Aug 13, 2026 Reopen(主 session,2026-08-13)—— 码到得了 main,到不了用户
PR #955已把 main 侧的提取收编成咽喉,那一半是对的、已合入。但票面症状说的是用户看到什么,
而在今天的 alpha 上实读确认:分类码在下一跳就被丢掉。packages/ui-mac/src/main/alpha-upload.ts:52 if ("error" in job) return fail(deps.log, "upload-dispatch-failed") packages/ui-mac/src/main/alpha-upload.ts:91 if ("error" in job) return fail(deps.log, "upload-dispatch-failed") packages/ui-mac/src/renderer/extensions/cloud-dispatch-box.tsx:46 return t("alpha.cloud.consent.errScope")#955的文件清单里没有alpha-upload.ts,也没有任何 renderer 文件。
⇒ 平台回400 + code: "upload_reserved_input"时:dispatchExplicitCloudUpload确实返回了那个码,
然后alpha-upload.ts把它坍缩成upload-dispatch-failed,renderer 再兜底成一句泛泛的「范围问题」。
用户依然看不到「你要的那条限制,这个执行形态根本强制不了」。顺带订正票面一处:症状段写「renderer 会把它原样贴在错误行里」—— 对上传路径不成立,
实际是被坍缩成泛泛文案,比原文描述的更糟。按「砍范围要闭合用户可达路径」与「判据落在用户可观察结果上」,本票的 AC 未达成,故 reopen
(不换身份,续做原票)。续做的边界(已收窄)
alpha-upload.ts:52 / :91不再把派发腿错误坍缩 —— 把咽喉产出的码原样上抛;cloud-dispatch-box.tsx的uploadError兜底走dispatchError(平台码原样透出),
而不是 catch-all 成errScope;- 判据必须钉在
.alpha-ext-card-err上(用户可观察那一端),两条不同字面量的码,
断言原文出现且不含errScope文案。
不要重做 main 侧的咽喉 ——
#955已经做了,那部分已在 alpha 上。现成产物
分支
fix/940-platform-error-code-chokepoint(PR#956已作废关闭,分支保留)里有上述三条的实现与判据,
绕过实验实测:兜底改回 catch-all ⇒ 恰好那两条 DOM 判据红。可直接摘取,但不要把那套平行咽喉一起带过来。同轮查出、不在本票的两件(已分别记在 PR #956 与 alpha-platform)
platform-error-code-gate.test.ts钉的是「import 咽喉的文件集合 == 枚举清单」,
钉住的是现有成员而非「新出网文件必须被归类」—— 一个从不 import 咽喉的新平台出口,那道闸看不见。deleteCloudSchedule的r.error !== "http-404"幂等容忍,依赖平台今天不给 404 补 code;
注释写的是结论,不是判据。
- added a commit that references this issue
on Aug 14, 2026
症状
packages/ui-mac/src/main/alpha-cloud-jobs.ts:172(dispatchExplicitCloudUpload)仍然是:而
#918已经给authed()那条路加了httpErrorCode(),从平台响应里取稳定分类码(
denied_paths_unenforceable_for_execution_form、upload_reserved_input、billing_unready…)。⇒ 走显式上传派发时被平台拒,用户看到的还是一个
http-400,而 renderer 会把它原样贴在错误行里 —— 「你要的那条限制,这个执行形态根本强制不了」那句诚实说明丢了。
上传路径恰恰是最容易撞上分类拒绝的一条(
upload_reserved_input、同意面相关的拒绝都在这里)。为什么单独一张票
#918的边界是cloud-envelope-guard.ts的注入策略与 dispatch 面的分类码消费。上传派发是另一条 fetch(带
x-alpha-upload-consent头、不过authed()),不在那张票的 diff 里。按「同一类第二次出现就从逐实例修切到枚举整类」:修法不是再补一处调用,而是
枚举所有「读平台 Response 并产出 error 字符串」的点,让分类码提取成为那条路的咽喉,
新增出口默认拒绝(没走咽喉即红)。
判据
code: "upload_reserved_input"⇒ 上传派发的 error 是那个 code,不是http-400http-400,不猜src/main下每个读平台 Response 产出 error 的点都必须经过分类码提取;新增即红来源
ac#400/ac#918合并后编排者复核发现(2026-08-12)。Refs jinjunnn/alpha-work#13