[SPIKE] settled(): await settledness instead of polling for it

[NullVoxPopuli-ai-agent]

Exploration for the RFC 957 test story (context: emberjs/ember.js#21520, the runloop-less scheduler spike). Draft — for signal and discussion, not to merge as-is. Depends on emberjs/ember-test-waiters#525 for waitersSettled (CI here will not typecheck until that lands and releases).

What changes

settled() stops polling isSettled on a timer cadence and awaits the settledness promises instead:

for (;;) {
  await Promise.race([
    Promise.all([renderSettled(), waitersSettled()]),
    new Promise((resolve) => setTimeout(resolve, 50)),
  ]);
  await new Promise((resolve) => setTimeout(resolve, 0));
  if (isSettled()) return;
}

Rendering is bridged into a test waiter, so on builds that report render edges (_onRenderSettledChange) a pending render is counted in hasPendingWaiters and is named in waiter debug output instead of being an anonymous isRenderPending boolean.

Why each piece survived review

Three things look deletable and aren't; each was measured after trying the deletion:

• the 50ms race — with settled() reduced to a bare await Promise.all([renderSettled(), waitersSettled()]), this repo's suite goes 553/553 → 5 failures. Run loop timers, legacy Ember.Test.registerWaiter callbacks, the request counter, and Waiters without settled() cannot announce completion. 50ms rather than 10 so it loses the race to a frame-paced render tick (at 10ms it decided 30 of 117 iterations; at 50ms, 1 of 92 — the promises decide in practice).
• the 0ms yield — quiet must be observed from a macrotask; already-queued task sources (worker messages, zero-delay timers) register waiters right after a microtask-context check says settled. ~1-in-4 flake without it on a worker-based compile suite. waitUntil imposed this implicitly.
• the render bridge — deleting it takes limber's tutorial suite from 71/71 to 10+ 20s timeouts. renderSettled() is one-shot ("is the work I asked about done?"); isSettled() is checked afterwards and needs a current render signal, which classic builds get from hasRunLoop and runloop-less builds otherwise have nothing for.

The helper functions those pieces lived in are gone — the logic is inline with its reasoning.

Validation

• This repo's test-app: 553/553 (against a linked build of the companion PR, and against published test-waiters where waitersSettled is absent and the fallback drives).
• Runloop-less ember spike, via the equivalent dist patches in settled() awaits renderSettled() instead of polling the render half NullVoxPopuli/limber#2214: full chrome matrix green (repl + tutorial + ember-repl), 7/7 repeat runs on the suite that exposed the macrotask flake.

🤖 Generated with Claude Code

[NullVoxPopuli-ai-agent]

Pushed a second iteration that goes further, and I think lands somewhere better: rendering becomes a test waiter.

Rather than the framework exposing a pollable isRenderPending() that isSettled() has to read as its own clause, the renderer reports the edges of its work (_onRenderSettledChange: true when rendering or destruction becomes outstanding, false when complete), and this addon bridges those edges into buildWaiter('@ember/test-helpers:render'). Consequences:

• isSettled() has no render-specific clause at all on such builds — a pending render is already counted in hasPendingWaiters (the old clause is hardwired false to avoid double-counting).
• A render that never completes is reported by name in test-waiter debug output, instead of as an anonymous isRenderPending: true boolean.
• Settledness becomes one push-based protocol rather than 'waiters, plus a separately-polled render flag'.

Runloop-driven builds are untouched — they still infer pending renders from backburner's autorun instance.

Validation: this repo's test-app 553/553 on stock ember; against the runloop-less spike build, limber's full app+addon chrome matrix green and 7/7 repeat runs on the suite that originally exposed the macrotask-confirm flake.

[NullVoxPopuli]

bad bot. this is not what I meant.

I meant in the test-waiters package, when we go beginAsync, we can have that be internally new Promise, and then endAsync resolves the promise.

test-waiters can have a waitersSettled() function which sees if all known promises are resolved (tho, if they resolve, I would also assume they remove themselves from the structure that waitersSettled() would look at)

[NullVoxPopuli-ai-agent]

Understood, and you're right — I built the aggregate version (one module-level deferred that resolved when hasPendingWaiters() went false), not per-operation promises. Redone as you described, in emberjs/ember-test-waiters#525:

• beginAsync creates a promise for that operation
• endAsync resolves it and deletes it from the pending map, so the map only ever holds work in flight
• waitersSettled() composes the promises of what's currently tracked, via a new optional settled() on each waiter

Your design is also strictly better than mine for a reason I hadn't considered: my version called hasPendingWaiters() on every endAsync, which walks every registered waiter and builds debugInfo arrays for the pending ones. Per-operation promises do no scanning at all — endAsync resolves one deferred.

One case the interface forced a decision on: a Waiter implemented directly against the interface has no settled() to compose. Rather than reporting a quiet it can't verify, waitersSettled() returns a never-resolving promise while such a waiter is pending, so the caller's fallback tick drives and pull-only waiters keep working.

Re-validated: test-waiters base-tests 56/56; this repo's test-app 553/553 both against a linked build of the new API and against published test-waiters (degraded to the fallback); limber's full chrome matrix green with 7/7 repeat runs against the runloop-less spike.

[NullVoxPopuli]

delete this function

[NullVoxPopuli-ai-agent]

Function deleted and inlined too. The 0ms yield it did stays, for the same measured reason as before: quiet observed in microtask context beats already-queued task sources (worker messages, zero-delay timers) that are about to register waiters or dirty state, and settled() returns early. That flaked ~1-in-4 runs on limber's worker-based compile suite until the yield was there; waitUntil had been imposing the same boundary implicitly by scheduling every check through setTimeout.

[NullVoxPopuli]

delete this function

[NullVoxPopuli-ai-agent]

Function deleted and inlined — but the 50ms timer itself has to stay, and I have data rather than an opinion on that now.

I first built exactly the minimal version (settled() = await Promise.all([renderSettled(), waitersSettled()]), no race, no loop, no yield). This repo's own suite goes from 553/553 to 5 failures:

not ok 9  - rerender real-world: using rerender to test loading states works
not ok 11 - Global error: calling set on destroyed object … internalValue = async value
not ok 12 - settled real-world scenarios: it works when async exists in `init`
not ok 13 - Global error: calling set on destroyed object … internalValue = async value
not ok 14 - settled real-world scenarios: rerender - it basically works

The reason is that not everything announces completion: run loop timers (hasPendingTimers), legacy Ember.Test.registerWaiter callbacks, the AJAX request counter, and any Waiter implemented against the interface without settled(). settled() returns while those are pending, and the destroyed-object assertions are the fallout.

With the timer inlined and the loop kept: 553/553.

[NullVoxPopuli]

why all of this condition? we don't care, right? because we can just await renderSettled()

[NullVoxPopuli-ai-agent]

settled() does just await renderSettled() — that part is unconditional now. But I tried deleting the bridge entirely and it doesn't hold up, so I'd rather show you the A/B than quietly keep it.

Same limber tutorial suite, runloop-less ember build, only difference is this block:

	result
bridge present	71/71 pass
bridge deleted	10+ chapters fail, each at the 20s test timeout

Reproducible, both directions, re-run to confirm.

The reason the awaited promise isn't sufficient: renderSettled() answers "has the work that was outstanding when I asked finished?" — one-shot. isSettled() answers "is anything outstanding right now?", and it is checked after the await, past a macrotask yield in which new dirt can land. Without the bridge, isSettled() has no render signal at all on runloop-less builds (hasRunLoop is false — there's no backburner), so a render that starts during that window is invisible and the loop exits with rendering pending. On classic builds hasRunLoop covers exactly this, which is why the gap only shows up on the runloop-less side.

So the bridge isn't a second settledness mechanism — it's how isSettled() keeps the render signal it already has on classic builds, expressed through the waiter protocol instead of a new isRenderPending() API. That framing is also what lets it be deleted the day rendering-pending is folded into waiters upstream in ember itself.

(I haven't traced the tutorial hang to the exact line inside its compile pipeline — what I can say confidently is the A/B above and that the missing sync signal is the only behavioural difference.)