Post-login landing ignores `isDefault` — cold sign-in always lands on `/_console/home` (and AppManagementPage's Disable / Set-as-default are client-only stubs)

[huangyiirene]

Symptom

A. Post-login landing ignores isDefault

With an app published carrying isDefault: true, four cold sign-ins in fresh browser contexts all landed on /_console/home instead of the default app.

• Observed: /_console/home (the multi-app launcher), 4/4 cold sign-ins.
• Expected: /apps/<the isDefault app>.
• Control that isolates it: navigating to /_console/ while already authenticated redirects correctly to the default app. So the resolver's policy is fine; the unauthenticated entry path is what breaks.

B. AppManagementPage's Disable app and Set as default are client-only stubs (confirmed)

Both controls show a success toast with zero non-GET requests on the wire and no server change on reload. Nothing in section A was credited off those toasts — the isDefault: true app was published through metadata, not set via this UI.

Root cause

A — the chain

1. On the unauthenticated first paint, GET /meta/app 401s.
2. apps/console/src/components/RootLandingRedirect.tsx resolves with an empty app list. resolveLandingPath([]) has no isDefault entry and no single visible app, so it falls through to rule 3 and returns /home. The resolver is auth-unaware — it only distinguishes loading from resolved, not "resolved empty because 401".
3. The auth guard then captures that already-wrong path into ?redirect=%2Fhome, and honors it after sign-in.
4. So the isDefault branch never re-runs once the app list is actually available.

Verified still present on objectui origin/main @ bb68488: resolveLandingPath is unchanged (const defaultApp = list.find((a) => a.isDefault === true) on a list that is empty at that moment), and RootLandingRedirect still renders Navigate as soon as loading is false.

Not a stale bundle — the pin contains the routing (apps/console/src/components/RootLandingRedirect.test.ts asserts the isDefault policy at the pure-function level, which is exactly why the policy tests stay green while the live landing is wrong: the tests never feed it the empty-because-401 list).

B — the stubs

apps/console/src/pages/system/AppManagementPage.tsx — the handlers behind Set as default, Disable/bulk toggle and Delete each carry a literal // TODO: Replace with real API call when backend supports app management immediately before their toast.success(...), then call refresh(). No mutation is ever issued. Still present verbatim on origin/main @ bb68488 (the file's only recent touch is the i18n pass in #4208, which did not change the handlers).

Note the interaction between the two halves: because B never writes, an operator cannot even work around A from the console UI — isDefault has to be set in metadata.

Reproduction

Framework a86db175, vendored console 09987b68, showcase app.

A:

1. Publish an app with isDefault: true.
2. Open a fresh browser context (no session) and go to /_console/.
3. Sign in.

Observed: lands on /_console/home; the sign-in URL carries ?redirect=%2Fhome. Repeated in 4 independent fresh contexts — 4/4.
Control: with an existing authenticated session, navigate to /_console/ — redirects correctly to the default app.

B:

1. Go to the Applications page (AppManagementPage) as an admin.
2. Click Disable app on an app, and Set as default on another.
3. Watch the network panel; then reload.

Observed: success toast both times, zero non-GET requests, no server-side change after reload.

Dedup

Searched objectstack-ai/objectui for RootLandingRedirect, post-login landing / default-app landing, and AppManagementPage disable / set-as-default stub symptoms — no open or closed duplicate found.

Source

Extracted from the QA run objectstack-ai/objectstack#7514 (framework a86db175, vendored console 09987b6). Root-cause re-verification is against objectui origin/main @ bb68488.

[yinlianghui]

CLAIM + 代决 — session session_017Qqyix2QcnpUC9XeYVDzx3(objectui whole-repo PM seat;否决窗口开放)。Branch: claude/issue-4233-default-app-landing。

两半的裁决框架:

A 半(落地忽略 isDefault)——原则:错误态的兜底路径不得被固化为用户意图。 401 导致的空列表是"未知",不是"没有默认 app";resolver 把两者混为一谈、auth guard 再把错误结论烤进 ?redirect= 使其永不重算,是本缺陷的两级放大。修复须让"因未认证而空"与"真空"可区分(单一事实源,不加第二个状态旗的方言),机制二选一由 dev 实测定:RootLandingRedirect 在未认证时不产出结论,或 guard 不捕获兜底路径、登录后重跑 resolver。核心 pin:冷登录 + isDefault app ⇒ 落 /apps/<default>(QA 的 4/4 反例变 0/4);已认证控制路径不回归;#4048 落的 Setup 排除 pin 不回归。

B 半(AppManagementPage 三个假成功 stub)——先测后裁: 实测 rc.6 服务端是否存在 app 管理写 API(set-default / disable / delete)。有 ⇒ 接线。无 ⇒ 撒谎的成功 toast 比没有控件更糟:改为禁用态 + 说明性提示(走 i18n),并报告以便本席向 objectstack 车道立 API 卡;绝不保留零请求 + success toast 的组合。两半的交互卡片已点明(B 不写 ⇒ 运维无法从 UI 绕过 A),PR 正文保留这条因果。

Surface:apps/console(RootLandingRedirect.tsx、auth guard、AppManagementPage.tsx)+ 测试。与在飞 #4278 互斥令:不碰 FormPage.tsx / createdRecordPath.ts 及 #4279 落的表单路由模块。

---

Generated by Claude Code

[yinlianghui]

ACCEPT — PM review of record (session session_017Qqyix2QcnpUC9XeYVDzx3)。

PR #4300 验收要点:

• A 半场,前提部分过期的处理正是想要的形状:链路第 3 环(guard 烤 ?redirect=)已被 objectui: 登录页在无会话时仍拉 /meta/*，登录前刷 30 条 401 报错，且日志打成 [object Object] 无法定位 #4042 在卡片立案前 24 小时关掉——dev 用 git show 对 QA 的 vendored bundle 做了考古确认,没有对已修的门再修一遍,而是把该门的行为双极性钉住(裸 / 不捕获、真实深链仍捕获)。活着的半场才是本 PR 的修复:有效会话下 GET /meta/app 失败 → ensureType 吞进 [] → "无默认 app"被 Navigate replace 化石化。修复用元数据 context 自己的 getTypeStatus('app') 做门——单一事实源,零新方言,resolveLandingPath 一字未动(ux(setup): 平台 SSO 后落地 Setup System Overview(全 0 审计仪表盘)— 新 builder 应落 /_console/home;Total Users 显示 0 #4048 pins 原样绿),错误路径从源头不再产出而不是在捕获点打补丁。unresolved 态 ref 限一次重问,可恢复而非死转。
• B 半场,TODO 前提被实测证伪:meta.saveItem/deleteItem + 路由账本 PUT/DELETE /api/v1/meta/:type/:name(ADR-0066 D1 门控)早已存在,useNavigationSync 一直在走同一通道。四个 handler 全部接线;set-as-default 先降旧再升新(两个 isDefault 持有者会让落地依赖服务器列表顺序)与 bulk 按实际落账计数,都是长期稳定性上的正确细节。
• 反向验证含一次预测修正且机制成立:多出的第 3 红(重问恰一次)只有在门把组件留在挂载态时才可达——不是噪音,是修复机制自身的证词。B 半场 12/12 双向红(缺客户端调用 + 拒绝时假成功)正是 stub 曾同时满足的一对。
• CI 20 项收敛,18 成功 + 2 设计跳过,零失败;minor changeset 合规。

连带采纳:AppManagementPage 整页 chrome 未 i18n(#4208 遍历未覆盖,本 PR 刻意零新增字符串)——单独立卡入队,不混入本 PR。

Flipping ready + auto-merge。

---

Generated by Claude Code