Console duplicates requests within one cold load (sys_user_preference ×3–×6, meta/object ×2, meta/view ×2)

[os-zhuang]

Tracked under objectstack-ai/cloud#1521 (performance epic). Dispatch round R1, parallel with the cloud-side cards — different repo, no territory overlap.

Console issues several requests to the same endpoint within a single cold load (page settles in 3.7s, far too short for pollers to fire a second time). Because the cloud control plane costs ~1.5s per DB-touching request (objectstack-ai/cloud#1518), each duplicate is both direct added latency and extra pressure on a concurrency knee.

Measured 2026-08-21

prod cloud.objectos.ai /_console/home, hard reload — 27 API calls, of which:

endpoint	count	individual durations
/api/v1/data/sys_user_preference	×3	2947 / 2913 / 2942 ms
/api/v1/meta/object	×2	2590 / 4455 ms
/api/v1/meta/view	×2	2609 / 4497 ms
/api/v1/auth/get-session	×2	831 / 1141 ms
/api/v1/runtime/config	×2	512 / 431 ms

staging cloud.objectos.app welcome, hard reload — 35 API calls, worse:

endpoint	count	individual durations
/api/v1/data/sys_user_preference	×6	8035 / 8027 / 7573 / 6511 / 7350 / 6242 ms
/api/v1/data/sys_notification_receipt	×2	7945 / 7059 ms
/api/v1/data/sys_inbox_message	×2	7819 / 6989 ms
/api/v1/auth/me/localization	×2	4976 / 4483 ms
/api/v1/auth/get-session	×2	2825 / 2377 ms
/api/v1/runtime/config	×2	1414 / 629 ms

On staging, 15 of 35 calls are duplicates.

Why this is worth more than it looks

Server cost is ~1.5s per DB request on prod and ~6s on staging, and it degrades sharply past ~10 concurrent (cloud#1518 §2: at 20 concurrent the median goes from 1.9s to 4.4s). The home page already issues 27 concurrent calls. Removing these 6–15 duplicates saves their own latency and pulls total concurrency back under the knee — the benefit is doubled.

Where to look

sys_user_preference ×3 (prod) / ×6 (staging) is the most suspicious: it looks like several components independently fetching the same user preferences with no shared provider or request dedup. meta/object / meta/view ×2 look more like a MetadataProvider bootstrap effect re-running.

A similar class was fixed once before — AppHeader's notification/approval pollers were coalesced from ×5 to 1 with mountedRef + an in-flight guard (PR #1477). The same technique may apply, but these duplicates occur across different components, which likely calls for dedup at the request layer (in-flight requests sharing a Promise per key) rather than a guard inside each component.

Reproduce

Log in to cloud.objectos.ai, open /_console/home, hard reload, then:

const api = performance.getEntriesByType('resource').filter(r => r.name.startsWith(location.origin + '/api/'));
const by = {}; for (const r of api) { const p = new URL(r.name).pathname; (by[p] ||= []).push(Math.round(r.duration)); }
Object.entries(by).filter(([,v]) => v.length > 1);

Related: objectstack-ai/cloud#1518 (~1.5s fixed server cost per request).

[os-zhuang]

统筹跟踪于 objectstack-ai/cloud#1521（Epic：性能）。派发轮次：R1，与 cloud 侧并行——不同 repo，无领地冲突。

[os-sales]

Claim: domain:ui execution seat, session session_012u2pRjcqAYtoEjgr3wwhnK · branch claude/issue-5544-console-request-dedup · round 5.

⛔ Measure before you choose a layer — this card's fix shape is NOT settled

The card says the fix "may apply" and "likely calls for dedup at the request layer". Triage added a tracking note (cloud#1521, round R1) and no scoping. So the fix shape is genuinely open, and that is the main hazard here: a request-layer change is the widest possible answer to this defect and the easiest to over-reach on.

Work it in this order, and report the measurement before the fix:

1. Find every caller of each duplicated endpoint and say why each one fires. My starting probe, to be re-derived not trusted — sys_user_preference reads live at packages/data-objectstack/src/userState.ts and packages/app-shell/src/chrome/CommandPalette.tsx. The card's ×3/×6 counts mean there are more callers, or one caller mounting repeatedly, and those are different defects with different fixes.
2. Classify each duplicate. The card already distinguishes two shapes: sys_user_preference looks like several components fetching independently with no shared provider, while meta/object / meta/view ×2 look like a bootstrap effect re-running. A re-running effect is fixed at the effect; independent callers need a shared cache or an in-flight coalescer. Do not apply one remedy to both without showing they are the same shape.
3. Prefer the narrowest fix that removes the measured duplicates.

⛔ If the only correct fix changes the contract of a shared request layer, stop and report before landing. That is an architectural change across every consumer in the workspace, and it is my call or the maintainer's, not a scope decision inside this card. Say what you would change and why the narrower options do not work.

The prior art the card names, and its limit

AppHeader's pollers were coalesced ×5 → 1 with mountedRef + an in-flight guard (PR #1477). The card correctly flags that this case differs: the duplicates here occur across different components, so a guard inside each component cannot see the other callers. Read that PR before reusing its technique — and if you conclude it does transfer, show why.

The test is where this card can go wrong

A "page renders correctly" assertion is green against every version of this code — nothing renders wrong, it just costs 6–15 extra requests. Assert on the request count per endpoint across one mount, with a stubbed transport, and pin both:

• the duplicate is gone (count is 1), and
• the data still arrives at every consumer that was fetching it — a dedup that starves the second consumer is a regression a count assertion alone would call a success.

The card's own reproduce snippet is a browser probe against prod; you cannot run it. Do not claim a production measurement you did not take — pin the behaviour in a unit test and say plainly that the prod/staging numbers are the card's measurement, not yours.

Scope

Whatever the measurement justifies, fenced to the caller sites and/or packages/data-objectstack/src/userState.ts, plus tests and a changeset. packages/app-shell/src/views/studio-design/** is held by #5476 this round — different directory, no overlap expected, but that is why an app-shell file may move under you.

Clause ②: not tripped by a dedup that preserves observable results. If your fix changes what a caller receives, or adds an export, stop and report.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
 "issue": 5544,
 "status": "done",
 "branch": "claude/issue-5544-console-request-dedup",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5593",
 "premise_still_valid": false,
 "summary": "The headline duplicate is a measurement artefact, and the two real shapes are already fixed. The card grouped resource timings by URL pathname, which discards the query string; ConsoleShell's UserStateBridge attaches THREE sys_user_preference adapters that differ only in the key predicate (ui.favorites, ui.recent, ui.flow.palette.recents), so prod x3 is the correct budget, not a duplicate. Measured on origin/main with a stubbed transport: one mount issues 3 calls with 3 distinct keys and zero repeats, and a StrictMode double-mount still issues 3 because ObjectStackAdapter.find() ALREADY coalesces in-flight reads on resource+params — the very request-layer dedup the card proposes adding. meta/object x2 and meta/view x2 were fixed under objectui#4042 and are already pinned green by MetadataProvider.requestBudget.test.tsx. auth/get-session x2 is by design (preflightAuth probes Bearer-only with credentials omit to detect a stale token; AuthProvider then asks who the user is) and deduping it would break stale-Bearer detection. No source change was justified, so the PR ships a regression pin instead — and it guards the card's own proposed remedy, which as endpoint-level dedup would collapse the three reads into one and starve two of three consumers while making a pathname-level count look perfect.",
 "tests": "All at final HEAD a615125e5, exit codes captured before any pipe. NEW packages/app-shell/src/console/__tests__/consoleUserPreferenceBudget.test.tsx: 'Tests 3 passed (3)'. Targeted union pnpm exec vitest run packages/app-shell/src/console/ packages/app-shell/src/context/ packages/app-shell/src/providers/ from repo root: 'Test Files 73 passed (73)' / 'Tests 516 passed (516)'. packages/data-objectstack/: 'Test Files 41 passed (41)' / 'Tests 558 passed (558)'. app-shell type-check exit 0 after pnpm --filter '@object-ui/app-shell^...' build (script name echoed, so not a zero-match no-op). app-shell lint: '2510 problems (0 errors, 2510 warnings)', all pre-existing; eslint on the new file alone emits nothing. check-control-bytes: 'OK (scanned 4647 tracked text file(s); skipped 85 binary)'. check-changeset-presence green via empty frontmatter (tests-only). check-changeset-no-major: 'No changeset declares a major bump.' check-changeset-fixed: 'All workspace packages are in the changeset fixed group.' ABLATION: mutated ObjectStackAdapter.find()'s coalescing key from resource+stableStringify(params) to resource alone — the card's proposed remedy read literally. No rebuild needed and that is proven, not assumed: vitest.config.mts line 272 aliases @object-ui/data-objectstack to packages/data-objectstack/src, so the test loads mutated SOURCE directly. Mutation proven on disk by anchored counts in both directions: original anchor 1 then 0, mutant anchor 0 then 1, git diff --stat '1 file changed, 1 insertion(+), 1 deletion(-)'. Result 2 of 3 RED — budget test 'expected [] to have a length of 1 but got +0' for ui.recent and ui.flow.palette.recents (three reads collapsed to one), consumer test 'expected [] to deeply equal [ object:contact ]' (consumers starved); the identical-in-flight-reads case correctly stayed green. Restored via trap on EXIT INT TERM; git status --porcelain empty, original anchor back at count 1, all 3 green again. DECLARED NARROWING: the full packages/app-shell/ suite (482 test files) exceeds the container's foreground cap (a full run was killed at exit 124), so it was narrowed to the three directories the new test imports from. This cannot hide a failure — the diff is 2 files with ZERO runtime source (one new test, one changeset), so no existing test's subject changed, and the dom project runs isolate: true (vitest.config.mts line 229; only the unit project sets isolate: false), so a new file cannot leak module state into another. CI runs the whole farm regardless.",
 "open_questions": [
 {
 "question": "The PR body says 'Part of #5544' rather than a closing keyword, deviating from the dispatch word. Merging it must not close the card, because the residual items below are unresolved — but that is your call, not mine.",
 "options": [
 "A. Keep 'Part of' — merge the pin, leave #5544 open for the residual triage below",
 "B. Switch to a closing keyword — treat the premise falsification as the card's full answer and close on merge"
 ],
 "recommendation": "A, because the staging x6 has no reproduction on this repo's main and the prod numbers may predate objectui#4042; closing on merge would bury both behind a green PR."
 },
 {
 "question": "The staging x6 (= 3 keys x 2) needs a second wave that escapes the in-flight coalescer, and I could not produce one from this repo's main. A StrictMode double-mount does not escape it (measured). The MetadataProvider key={language} remount would, but languageSeed.ts deliberately commits the language BEFORE React mounts and documents that it must never flip late.",
 "options": [
 "A. Re-measure staging against a build of current main and re-file only if it survives",
 "B. Investigate in the cloud repo (cloud#1521), since the measured host is a cloud deployment whose shell is outside objectui",
 "C. Leave as-is — the x6 is 3 legitimate keys doubled by a dev-build double-mount, costing nothing in production"
 ],
 "recommendation": "A then B — the whole-table x2 on staging (get-session, runtime/config, localization, notification_receipt, inbox_message ALL x2) is the signature of the entire tree mounting twice, which points at a dev build being served rather than at any single caller in this repo."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code