[armando-navarro]

Fixes #3826

• Adds blockUntilFirst: false entries to tools/build.ts for ten callback-taking calls whose first callback a normal load may never run.
• Replaces the generated fromRef with a hand-written one in src/database/overrides.ts that holds the app only for the value event.
• Moves the isSupported entry zone log verbosity #3613 meant for firebase/remote-config into the block that exports it.
• Regenerates the five affected files.

Checklist

• Issue number for this PR: Eleven wrapped callbacks and remote-config isSupported hold the app unstable until something that may never happen #3826
• Docs included?: in docs: document the 22.0.0-rc.1 changes #3835, the 22.0.0-rc.1 docs PR, which merges just before the release. Its first commit lists in docs/zones.md the calls that no longer hold the app unstable, and adds a sentence each under stateChanges, auditTrail and fromRef in docs/database.md.
• Test units included?: yes, see Verification.
• Breaking change?: no
• In a clean directory, yarn install, yarn test run successfully?: yes, with npm: npm ci, npm run build, npm run build:jasmine, npm run test:node, npm run test:chrome-headless, npm run lint.

Changes

The mechanism:

• ɵzoneWrap registers a pending task when a wrapped call is passed a callback.
• It releases the task when that callback first runs or the returned unsubscribe is called.
• Until then ApplicationRef.isStable is false: an SSR build's route extraction times out after 30 seconds (the beforeAuthStateChanged imported from @angular/fire/auth makes ng build fail during route extraction #3748 failure), and anything waiting on stability in the browser waits with it.

The ten calls whose first callback is not guaranteed, now { blockUntilFirst: false, logLevel: LogLevel.WARN }:

• onLog: never stable until some Firebase SDK logs. It returns void, so no unsubscribe can release the task either.
• onTokenChanged: never stable until a token is obtained, which a first visit with no auto refresh and no protected request never asks for.
• onChildAdded: never stable on an empty node. A new listener's initial events are only child_added, one per existing child, and value.
• onChildChanged, onChildMoved, onChildRemoved: never stable until someone changes, moves or removes a child. None fires on attach.
• off(query, eventType, callback): never stable. It never calls the callback it is given and returns void.
• enableLogging(fn): never stable until the database SDK logs something.
• stateChanges and auditTrail (rxfire, default events): never stable on an empty node, since they emit only on child events.
• Keeping logLevel: LogLevel.WARN means only the pending task changes: callbacks are still re-entered into the zone and the injection context, and a call outside an injection context still prints its per-function line at the warning level.

fromRef(ref, event) in @angular/fire/database, now hand-written:

• One blockUntilFirst value cannot fit both of its uses: the value event always fires on attach, and a child event on an empty node never fires.
• The new src/database/overrides.ts wraps rxfire's fromRef twice at module load, once holding the app until the first emission and once not, and picks by event. tools/build.ts marks it { override: true }, so the generated file re-exports it.
• The exported type is rxfire's own, typeof fromRef.

isSupported in @angular/fire/remote-config, now { blockUntilFirst: false }:

• With true, every call in a browser with IndexedDB held a pending task until the indexedDB.open it awaits answered, and for good in a browser that never answers.
• zone log verbosity #3613 added isSupported: { blockUntilFirst: false } for it, matching the analytics and messaging entries, but in the rxfire/remote-config block, which exports no isSupported. Overrides match by name, so it did nothing.
• build: classify the firebase symbols a version raise would newly wrap #3759 added the check that fails the build on such an entry, deleted this one and deferred the move.

What callers can notice

• A server render no longer waits for the first batch of onChildAdded children, so the server HTML of a list filled that way can ship before they arrive (reasoned from the wrapper, not run).
• onValue, object, list and fromRef(ref, ListenEvent.value) deliver a value on attach, empty node or not, and still hold the render.
• fromRef with a child event no longer holds the render, matching onChildAdded and stateChanges. To make a server render wait for a list's initial contents, use list(ref) or listVal(ref), which start with a one-time read and still hold it.
• off(ref, eventType, callback) no longer holds the app, but it still detaches nothing, because the wrapper replaces the callback with its own closure before the SDK compares callback identities.
• The unsubscribe returned by onValue and onChild* is the supported way to detach.
• Code that awaits ApplicationRef.whenStable() before chained Remote Config work no longer waits for isSupported.
• Inside isSupported's .then, inject() throws and the zone is the one that attached the .then, at both flag values, so the callback sees no difference.
• isSupported outside an injection context now logs its per-call line only at the verbose level, as the analytics and messaging copies do.

Verification

• Measured in Chrome on a zone.js Angular 22 app and a zoneless one, against the Database and Firestore emulators.
• Each run recorded every ApplicationRef.isStable emission and counted PendingTasks.add calls.
• At true, the never-firing cases above registered a task that was never released.
• At true, onChildAdded on a populated node, onValue, onSnapshotsInSync and onTokenChanged with auto refresh on released theirs within 2 to 23 ms, and onChildChanged released as soon as a child was written.
• At false, no task was registered in any run, and inside every callback that ran inject() worked and, under zone.js, NgZone.isInAngularZone() was true.
• A fresh Angular 22 SSR app with onLog in provideAppInitializer: ng build fails at the route extractor's 30-second timeout with Routes extraction was aborted when onLog comes from @angular/fire/app, and builds in about 2 s from firebase/app.
• isSupported at true holds the app unstable until the IndexedDB check answers, tens of milliseconds in Chrome, and for the whole window when indexedDB.open is stubbed to never fire. At false it registers no task.
• Specs: 19 new in src/app/app.spec.ts, src/app-check/app-check.spec.ts and src/database/database.spec.ts, and 1 in src/remote-config/remote-config.spec.ts. Each asserts whether the call registers a pending task.
• The app, app-check and database spec files each have a positive control proving the spy sees the wrapper's registrations, and fromRef has one spec per event kind.
• Dropping onLog, onChildChanged or isSupported from tools/build.ts and rebuilding fails the matching spec, and so does making the hand-written fromRef always wait or never wait.
• npm run build regenerates with the unrecognized-override check passing, and npm run test:node, npm run test:chrome-headless and npm run lint pass.

[tyler-reitz]

One blocking point: the fromRef override applies to every event, not only the child events the body describes.

In rxfire, object(query) is fromRef(query, ListenEvent.value), so after this change object(ref) still holds the render but the documented fromRef(ref, 'value') doesn't. A probe spec on this branch shows it: fromRef(ref(database, rando()), ListenEvent.value) registers 0 pending tasks, while object(ref(database, rando())) registers 1. On main, fromRef is generated with true, so I'd expect it to register one there (read from the generated file, not run).

Overrides match by name, so I don't think tools/build.ts can narrow this, and the tradeoff may well be right, since a child-event fromRef can hang forever. Either way, please add it to "What callers can notice" and to the docs follow-up, plus a spec pinning the 'value' case so the behavior is deliberate rather than incidental.

Non-blocking: two stray blank lines in the database override block in tools/build.ts, after enableLogging and after onChildRemoved.

Everything else checked out: a fresh build regenerates the five files byte-identical to the PR, and Chrome headless passes 132/132 locally.

[armando-navarro]

Thanks, Tyler. Rather than document the value case losing its wait, I made fromRef determine blockUntilFirst per event. It uses { override: true } to wire up a hand-written fromRef in src/database/overrides.ts, which:

• wraps fromRef with blockUntilFirst: true for ListenEvent.value.
• wraps fromRef with blockUntilFirst: false for everything else.

So fromRef(ref, ListenEvent.value) holds the render again, like object(ref), and child events still don't.

Specs cover every event: value registers exactly one task, and each of the four child events registers none. Making the selector always wait, never wait, or wait for any child event fails the matching spec.

The PR description now says the above.

The two blank lines are intentional: each marks where the comment above it stops applying, so orderByChild and endAt don't read as covered by it.

[tyler-reitz]

Thanks, the per-event fromRef override resolves my blocking point. I confirmed the new specs go red when the override is forced to never wait (value spec) and always wait (all four child specs), and a fresh build regenerates the five files byte-identical. One small thing for the squash: the first commit's body still lists fromRef among the calls that no longer hold the app, so please drop it from that list in the final message.