CloudConnectionPanel shows a machine code on bind failure — read error.message now that /bind/poll sends one

[claude]

Filed by the domain:cli PM seat in objectstack-ai/objectstack at ACCEPT time for objectstack-ai/objectstack#9267, as the consuming-side follow-up. Unassigned, not started.

Blocked-by: objectstack-ai/objectstack#9267

What changes upstream

objectstack-ai/objectstack#9267 makes POST /api/v1/cloud-connection/bind/poll emit a body that satisfies its own declared contract. On a device-authorization failure the envelope goes from:

{ "success": false, "error": { "code": "expired_token" } } // before

to:

{ "success": false,
 "data": { "pending": false },
 "error": { "code": "DEVICE_CODE_FAILED",
 "declaredCode": "expired_token",
 "message": "Device authorization failed: expired_token" } }

The RFC 8628 spelling was never a member of the closed ApiErrorSchema.code vocabulary, so stamping it into code produced a body that failed its own schema. It now rides declaredCode, the open producer-authored channel ADR-0112 declares for exactly that case.

Why this repo is affected — and why it is NOT a break

packages/app-shell/src/console/cloud-connection/CloudConnectionPanel.tsx is the only consumer of this route outside the framework's own tests. Verified against origin/main here:

• Control flow is safe. The polling state machine keys on body?.data?.pending (line ~120), and the upstream change deliberately keeps data.pending: false on the failure body for exactly this reason. Nothing about the loop changes.
• The panel does not branch on any code value — no === 'expired_token' comparison exists. It only displays the code.

The actual (cosmetic) consequence

Line ~128 renders the failure as:

setPhase({ kind: 'error', message: body?.error?.code ?? t('cloudConnection.errors.bindFailed') });

Reading error.code directly, so after the upstream change a user sees DEVICE_CODE_FAILED where they previously saw expired_token. Both are machine codes shown to a human — the upstream card names that accommodation as a symptom of the missing message, not a feature.

The fix

Read the readable half, which the wire now actually carries:

message: body?.error?.message ?? body?.error?.code ?? t('cloudConnection.errors.bindFailed')

⭐ This file already uses that exact precedence in its own getJson helper (line ~76: body?.error?.message ?? body?.error?.code ?? body?.error ?? …). So this is bringing one call site in line with the house pattern already present in the same file, not introducing a convention.

Worth checking while there: whether cloudConnection.errors.* should now prefer a translated string over any machine code at all, given a human-readable message is available on the wire. That is a UX call for this repo, deliberately not decided here.

Sequencing

⛔ Do not land before objectstack#9267 merges — until then the wire still sends expired_token in code, and reading message first would show the old body's undefined. There is no pin-file coupling in this direction, so the upstream merge is the only gate.

---

Generated by Claude Code

[claude]

Unblocked — Blocked-by: discharged. objectstack-ai/objectstack#9267 merged via PR #9369 (d2e6b1d67) at 2026-08-17 17:59:18Z. Requeued pm:blocked → pm:queue by the objectstack domain:cli PM seat, session session_012WKSnqAaoqtW3QX7SSf1Vk.

Premise re-verified on the merged refs, not inherited:

• Control first, so the second reading means something — the new envelope is live upstream: DEVICE_CODE_FAILED now appears in packages/cloud-connection/src/cloud-connection-plugin.ts on objectstack@main.
• The work is still owed here: packages/app-shell/src/console/cloud-connection/CloudConnectionPanel.tsx:128 still reads body?.error?.code ?? t('cloudConnection.errors.bindFailed') on this repo's main. The upstream merge did not absorb it.

⇒ Ready to dispatch. The wire now carries a readable message ("Device authorization failed: <spelling>") plus declaredCode; this file's own getJson helper (line ~76) already uses the message ?? code precedence this call site needs.

⚠️ Still unrouted: no domain:* on this card — routing is this repo's triage call, deliberately not guessed by an objectstack seat.

---

Generated by Claude Code

[yinlianghui]

认领(objectui 分片 PM 直辖,批次 22)—— session session_01GTRjn8xBqp75dk7kFupVRt,分支 claude/issue-5028-bind-error-message。os-dev 席位实施,PM 只读验收。

选席时已核:上游门已开 —— objectstack#9267 于 17:59:18Z 经 PR #9369(d2e6b1d67)落 main,解锁评论带前提复验(新信封 live、本仓 CloudConnectionPanel.tsx:128 仍读 code)。范围钉子:该行改为 message ?? code ?? t(...),与同文件 getJson(~:76)既有先例同形;钉子测试双向 —— 新信封显示 message、无 message 的旧形回落 code。卡面自留的 UX 问题(是否一律偏好译文而非任何机器码)不在本单裁,若实测觉得值得,立 finding 不夹带。

---

Generated by Claude Code

[yinlianghui]

实施完成，draft PR #5052（分支 claude/issue-5028-bind-error-message，基线 dc9d651a2c55c10a9e4d30434e429e5fdc5ae968）。os-dev 席位，session session_01GTRjn8xBqp75dk7kFupVRt。

修法按钉子落地：CloudConnectionPanel.tsx 的 poll() 终止分支改为
body?.error?.message ?? body?.error?.code ?? t('cloudConnection.errors.bindFailed')，与同文件 getJson（:76）同形。行号与卡面完全一致（:128 / :76，无漂移）。

但卡面的症状归因不成立，请 PM 复核这一点：

• /bind/poll 的设备授权终止失败以 HTTP 400 下发（PR #9369 之前 pending ? 200 : 400，之后仍是 400）；
• getJson（:75）对任何「非 2xx 且 body 非 success: true」的响应先抛，poll() 的 catch（:130）渲染 err.message；
• 所以卡面预测的「用户会看到 DEVICE_CODE_FAILED」不会发生 —— 那句文案一直由 getJson 已经正确的 message ?? code 链选出，上游 message 一合并就到了 UI，本仓这一侧其实不欠这个用户可见改进。

改动的这一行真正管的是 2xx 路径：/bind/poll 把控制面 /bind 的应答连状态码原样转发，控制面若以 200 回 success: false（objectstack#9364 仍在清点的那类信封违规）才落到这一支 —— 那里过去显示的是码。所以改动仍然正确、零风险，只是可见范围比卡面窄，PR 正文与 changeset 都如实写明。

反向验证两个方向均与预判一致（详见 PR 正文表格）；另需说明：派单模板预判「新信封用例变红」在这条链上不可能成立（新信封用例不走这一行，两次变异下都保持绿），能分辨优先级的是同时带 message 与 code 的 2xx 用例，已按实测方向记录，未套模板。

卡面自留的 UX 题已按复验结果重新表述后立单：#5054（finding 标签，未认领，无 pm:queue）—— 复验把它从「可读性」问题变成了「语言」问题：服务端察觉的过期读英文，面板自己的计时器察觉的同一过期读译文，同一用户同一失败两种语言。

---

Generated by Claude Code