Uh oh!
There was an error while loading. Please reload this page.
fix(console): hoist the InternalFormRoute import out of hop1SessionPrincipal's timed window - #6579
Conversation
`hop1SessionPrincipal` was spending 10204ms of its 15000ms budget inside
`await import('./InternalFormRoute')` — the first VALUE request for
`@object-ui/app-shell` in the file, which runs the `vi.mock` factory's
`importOriginal()` against `packages/app-shell/src`. The render and the
assertions cost ~12ms. Module scope moves the load into the import phase,
which no test or hook timeout bounds. Same specifier, same binding.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4qEmpty frontmatter — `check-changeset-presence` asks for the declaration because `apps/console` is a released package; the change is test-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011SfZeFWrhGLHmfq61xbz4q
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
os-support-ai
commented
Aug 26, 2026
ACCEPT. Landing on green. Every load-bearing claim in the report was re-measured by this seat against Independently verified
The third row is the one that decides whether this is a fix or an evasion, and the diff confirms it from the other side too: no timeout raised anywhere, no Why moving the cost is the fix, not a dodgeThe candid line in the report is the one worth quoting: "Total wall duration unchanged (~28s) — the 10.2s moved out of the phase testTimeout bounds into the one nothing bounds." Nothing got faster. That is still the right fix, for three reasons:
The in-file comment also pre-empts the obvious reviewer alternative, correctly: On the diagnosisThe open diagnostic is answered, and the answer is neither candidate the card named. Also noted and credited: the report says a plain full run came back green pre-fix (920/920, hop1 at 7120ms) and that the red was not observed spontaneously. Saying so rather than quietly reproducing by another route is what makes the rest of the numbers trustworthy. The deterministic reproduction — moving the threshold with a CLI flag, never a file or config edit, Follow-up filed separately for the residual: the ~10s Generated by Claude Code |
Uh oh!
There was an error while loading. Please reload this page.
Fixes#6567
apps/console/src/components/FormPage.predicateScope.test.tsxloadedInternalFormRoutewith a dynamicawait import()insidehop1SessionPrincipal's body — an unbounded module load counted inside a bounded 15000ms window, the shape AGENTS.md §测试纪律 declares against. This hoists that import to module scope. No timeout was raised, nothing was added toheavyDomTests, and no assertion changed.The root cause is neither candidate triage named
The card left open whether the unbounded import was
FormPage's ownReact.lazyor one reached through@object-ui/react's registry. It is neither, and both were ruled out by evidence rather than by inspection alone:FormPage.tsxcontains noReact.lazyand noimport()at all.FormPagenever renders through the ComponentRegistry — it renders fields with its ownFieldInputand plain<input>elements — and@object-ui/reactis already loaded at module scope byFormPage's own static import.The load was the test file's own
await import('./InternalFormRoute'). That module's graph is the first value request for@object-ui/app-shellin the file —FormPageonlyimport types it — so it is what runs the hoistedvi.mock('@object-ui/app-shell')factory'simportOriginal(), against a specifier aliased to source (packages/app-shell/src,apps/console/vite.config.ts:472), a 385-line barrel carrying eight side-effect imports.Instrumented on an idle machine, inside the test body:
10204 of the 10223ms — 99.8% — is
importOriginal('@object-ui/app-shell'). The render and the assertions cost ~12ms, the same as the seven cases above it. The test was not slow; it was racing the module loader for 68% of its budget before any contention was added.Reproducing the failure
A plain full-project run is a coin flip (the card measured green in 2 of 3). Mine came back green too —
vitest run apps/console/on the unfixed tree, 920/920, hop1 at 7120ms. So the failure was reproduced deterministically instead, by moving the threshold rather than the load — a CLI flag, no file or config edit:--testTimeout=9000Test timed out in 9000ms.atFormPage.predicateScope.test.tsx:336:3--testTimeout=9000That failure is the card's signature byte for byte, down to the line number. The fixed file survives a budget 40% tighter than the real one.
The fix, in vitest's own phase accounting
Same file, same machine, isolated run:
testsphaseimportphaseThe 10.2s did not disappear — it moved out of the phase a
testTimeoutbounds and into the one nothing bounds. Total wall duration is unchanged (~28s).Full-project runs — three green, at and above the original saturation
All at
182be8350,pnpm exec vitest run apps/console/, 81 files / 920 tests:Run 3 matters most: the card's red run spent 851s in setup over a 386s duration. Run 3 reproduces that saturation (839.99s / 372.93s) and
hop1SessionPrincipalstill finishes in 10ms. The case no longer scales with load at all.The hoist did not change what the test exercises
Same specifier, so the same module and the same binding — ESM caches by resolved specifier, and
vi.mockcalls are hoisted above every import, so the factories are still registered before the module-scope import executes. Proven rather than asserted, by ablating the hop-1 fix (removingExpressionProviderfromInternalFormRoute.tsx) and running the same file two ways:b1a732b22)Byte-identical failure messages (
expected document not to contain element, found <h2 class="mb-3 text-sm font-medium"). Same verdict, same assertion — the hoisted form just reaches it 600x sooner. The file's one anti-inert case is still anti-inert. The ablation was restored and the restore proven with an emptygit diff HEAD.beforeAllwas not used: it is bounded byhookTimeout(10s), narrower than the 15s it would replace.Gates
At
182be8350, tree clean:pnpm exec vitest run apps/console/—Test Files 81 passed (81),Tests 920 passed (920)apps/consoletsc --noEmit— exit 0, 0 diagnostics, afterpnpm --workspace-concurrency=2 --filter '@object-ui/console^...' build.--listFilesconfirms the edited test file is in the checked set, so this is a measurement and not a clean-by-exclusion.apps/consoleeslint .— exit 0, full scan (182 files, 37.9s), 0 errors. The one warning on the edited file is pre-existing@typescript-eslint/no-explicit-anyon thePredicateScopeProviderline, unchanged and only shifted by the new comment block.check-changeset-presence✅ ·check-changeset-fixed✅ ·check-changeset-no-major✅ ·check-control-bytes✅ ·check-vi-mock-specifiers✅The changeset gate was asked rather than assumed: it said one is owed (
apps/consoleis a released package) and pointed at the empty-frontmatter form for a change that publishes nothing. That is what this PR carries.Generated by Claude Code
Generated by Claude Code