objectui: 登录页在无会话时仍拉 /meta/*，登录前刷 30 条 401 报错，且日志打成 [object Object] 无法定位

[os-zhuang]

Migrated from objectstack-ai/objectstack#5751 under the file-at-destination ruling (objectstack-ai/objectstack#7167, maintainer 2026-08-10). Originally filed 2026-08-06T03:56:54Z. The full prior thread — including triage rulings and hold/restart conditions — remains on the source issue and MUST be read before acting on this card.

---

浏览器 dogfood 时发现（最新 main 5e3c83bd0 + objectui 5a24ad9cb89c）。前端侧问题，故打 repo:objectui。

现象

打开 /_console/（未登录，停在登录页），还没输入任何东西，浏览器控制台就已经刷了 30 条：

[error] HTTP request failed  [object Object]
[error] HTTP request failed  Object
… ×30

网络面板看，登录页在没有会话的情况下反复发认证接口，每轮 5 条 401：

GET /api/v1/auth/get-session   → 200 OK      ← 已经知道没有会话了
GET /api/v1/meta/object        → 401 Unauthorized
GET /api/v1/meta/view          → 401 Unauthorized
GET /api/v1/meta/app           → 401 Unauthorized
GET /api/v1/meta/object        → 401 Unauthorized   ← 同一轮里重复
GET /api/v1/meta/view          → 401 Unauthorized   ← 同一轮里重复

这一轮共重复 3 次（3 次渲染周期）＝ 15 条 401，每条打 2 行日志 ＝ 30 条控制台报错。

登录之后同样这几个接口全部 200。为确认登录后是干净的，我在页面里挂了个 fetch 探针，然后走了 8 条路由（command center / ops dashboard / revenue pulse / task 列表 / 4 张报表）：

{ "visited": ["ok showcase_command_center","ok showcase_ops_dashboard","ok showcase_revenue_pulse",
              "ok tabular","ok showcase_hours_by_status","ok showcase_hours_by_status_chart",
              "ok showcase_status_priority_matrix","ok showcase_task_overview"],
  "failures": [] }

零失败。 所以这 30 条报错完全来自登录前那一段。

两个独立的小问题

1）无会话时就发起需要会话的请求。 get-session 已经返回了「没有会话」，紧接着仍然去拉 /meta/object、/meta/view、/meta/app。这些请求注定 401，是纯浪费；而且同一轮里 meta/object、meta/view 各发了两次，说明还多了一次重复触发。

2）报错日志把错误对象打成了 [object Object]。 这是更影响排查的一条：30 条报错里没有任何一条能告诉你是哪个 URL、什么状态码。真要定位只能自己去翻网络面板。日志这里应该展开成 method + url + status（至少别做字符串拼接把对象吞掉）。

影响面

• 功能无影响：登录后一切正常，上面 8 条路由零失败。
• 影响的是开发与排查体验：任何人打开控制台第一眼就看到 30 条红色 HTTP request failed，而它们既不指向真问题、也不含可用信息。本次排查中我一度以为应用真的坏了，是逐条比对网络面板才确认全是登录前的噪音。
• 服务端日志同样会多出这批 401。

建议方向（实现者自选）

1. 登录路由下，等 get-session 确认有会话再拉 /meta/*（或者让这些 query 依赖会话状态作为 enabled 条件）；顺带查一下同一轮里 meta/object / meta/view 为何各发两次。
2. HTTP 客户端的错误日志展开成结构化字段（method/url/status/code），不要落成 [object Object]。这条即便 1 不做也值得单独做 —— 它决定了下一次真出问题时，控制台是能用的还是没用的。

复现

1. 起一个 dev 实例，浏览器打开 http://localhost:<port>/_console/，不要登录
2. 开控制台 → 30 条 HTTP request failed [object Object]
3. 网络面板筛 api/v1 → 15 条 401，全部在登录 POST 之前

[yinlianghui]

Claim: PM loop round 2 (objectui whole-repo seat — queue fill per the maintainer's 2026-08-10 five-concurrent directive)
Session: session_017Qqyix2QcnpUC9XeYVDzx3
Branch: claude/issue-4042-login-meta-401-noise
Worktree: objectui-issue-4042
Domain: repo:objectui (whole-repo seat)
File surface: (1) the session-gating of /meta/* queries on the login route — expected in app-shell's metadata/session providers; (2) the HTTP client's error logging (structured method/url/status instead of [object Object]) — expected in the shared data/HTTP client layer; plus tests. ⛔ Region-exclusive vs in-flight siblings: not the create-dialog/form-seeding path (#4047), not containers.tsx (#4027), not packages/cli (#4061/#4062), not packages/fields (#4059), not GridField* (#3569 branch).
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: no open claim or PR on the auth-bootstrap/HTTP-logging paths; #4047 (in flight) shares packages/app-shell at most at the package level — regions declared disjoint, merge origin/main before opening the PR and again after the sibling lands.

Source triage (objectstack#5751, promoted from finding 2026-08-06): two independently deliverable halves; the logging half is worth doing even alone. No holds or rulings on the source thread.

---

Generated by Claude Code

[yinlianghui]

ACCEPT (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4078.

What shipped, both halves: (1) session gating — the console's landing route now sits behind AuthGuard (it mounted the whole data layer anonymously before) and ConnectedShellInner withholds the metadata tree until get-session resolves, so no /meta/* fires before the session answer for any consumer; (2) structured HTTP failure logging — method/url/status/code now live in the message string itself (HTTP request failed: GET /api/v1/meta/object -> 401 [UNAUTHORIZED]), ending [object Object], with the structured bag still attached and nothing newly silenced (a post-gate 401 stays a visible, identified error — pinned).

The card's "investigate the doubling" clause paid off beyond its premise: the double-fire was measured to be auth-independent — MetadataProvider's preview-mode effect cleared the cache on mount, discarding render-phase fetches mid-flight and doubling meta/object+meta/view on EVERY mount, signed-in included; that's fixed (the mount-run skip), plus a ~1s failure back-off distinct from the 5-minute TTL so a failed type isn't hammered while refresh()/invalidate() still bypass immediately. Before/after on the real provider stack: 5 requests → 3 per mount — the fix removed two requests from the signed-in path too.

Review notes: measurement-first (the recording harness reproduced the card's exact table), reverse verification 14/15 red with the one green being the non-regression direction, reported as-is instead of reshaped. Post-merge re-run of every gate after origin/main advanced ~35 files. Small declared public-surface addition (formatHttpFailureMessage/createQuietHttpLogger exports for testability) noted in the changeset. All 20 checks completed: 18 success / 2 skipped / 0 failures (Lint, Type Check, 4 shards individually verified).

Landing next: flipping ready and driving to MERGED.

---

Generated by Claude Code