Skip to content

test(ui): non-blocking startup hydration invariant — first usable load (first-5 strike F2 port) - #16885

Merged
0xSolace merged 1 commit into
elizaOS:developfrom
0xSolace:sol/f2-port-nonblocking-hydration
Jul 23, 2026
Merged

test(ui): non-blocking startup hydration invariant — first usable load (first-5 strike F2 port)#16885
0xSolace merged 1 commit into
elizaOS:developfrom
0xSolace:sol/f2-port-nonblocking-hydration

Conversation

@0xSolace

Copy link
Copy Markdown
Collaborator

What & why

Ports the non-blocking-startup regression contract from milady-ai/milady#2209
(wrong repo — the demo deploys from here) to elizaOS/eliza.

The milady code fix is not needed on this repo. eliza's
runHydrating() already runs every shell-decoration fetch
(getWalletAddresses, getConfig, getStreamSettings, fetchAutonomyReplay)
inside decorateShellAfterReady(), fired after dispatch({ type: "HYDRATION_COMPLETE" })
(the #15178 lineage; last touch #16292). The serial-await structure milady#2209
targeted does not exist on this path.

So this PR lands the durable piece: a regression test that pins that
deferral so a future refactor cannot silently re-await a slow decoration call
on the ready critical path (the exact regression class milady#2209 fixed).

packages/ui/src/state/startup-phase-hydrate.nonblocking.test.ts — hangs every
non-critical dependency forever and proves:

  • HYDRATION_COMPLETE still fires (<3s);
  • the wallet fetch is kicked off but its setter never runs before completion →
    proves it's off the critical path;
  • autonomy replay is invoked but never awaited pre-completion.

Where the demo stall actually is (receipts)

A live staging startup-trace (window.__ELIZA_STARTUP_TRACE__, #9565) shows the
canary's ~13.6s post-login stall is not in the hydrate window:

coordinator mark at (ms)
first-run-required 1763
starting-runtime 14195
hydrating 14208
ready 18365

The 12.4s cost is first-run-required → starting-runtime (login/session establish

  • agent-base resolution), and hydrating → ready (~4s) is dominated by the
    post-ready agent-base fetch waterfall + lazy chunk loads — not the awaits
    milady#2209 removed. Full decomposition + follow-up levers in
    projects/eliza-fleet/F2-PORT-2026-07-22.md.

Test evidence

bun run test -- src/state/startup-phase-hydrate
 ✓ …nonblocking.test.ts (3)     <-- new
 Test Files  6 passed (6)   Tests  37 passed (37)
biome check …nonblocking.test.ts → clean

Reference: milady-ai/milady#2209
Part of the first-5-minutes demo strike (F2 port).

Co-authored-by: shadow shadow@shad0w.xyz

…e F2 port)

Ports the regression contract from milady-ai/milady#2209 to the demo repo
(elizaOS/eliza). The milady code fix (defer wallet, background VRM/world
prefetch, parallelize config reads, void autonomy replay) is UNNECESSARY here:
eliza's runHydrating already runs all shell-decoration work
(getWalletAddresses / getConfig / getStreamSettings / fetchAutonomyReplay)
inside decorateShellAfterReady(), fired AFTER dispatch(HYDRATION_COMPLETE),
via the elizaOS#15178 lineage. So the app-core serial-await structure milady#2209
targeted does not exist on this path.

This test pins that invariant so a future refactor cannot silently re-await any
of those slow calls on the ready critical path: every decoration dependency
(wallet, config, stream settings, autonomy replay) hangs FOREVER and the test
proves HYDRATION_COMPLETE still fires (<3s), the wallet fetch is kicked off but
never blocks (its setter never runs before completion), and autonomy replay is
not awaited.

Evidence that the canary's 13.6s post-login stall is NOT in the hydrate window:
a live staging startup-trace (projects/eliza-fleet/F2-PORT-2026-07-22.md) shows
coordinator:hydrating -> coordinator:ready is ~4s and dominated by the
post-ready agent-base fetch waterfall + lazy chunks; the real 12.4s stall is in
first-run-required -> starting-runtime (login/session establish + agent-base
resolution), a separate phase this PR documents for follow-up lanes.

Co-authored-by: shadow <shadow@shad0w.xyz>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant