[armando-navarro]

Checklist

• Issue number for this PR: Remove a callback read's pending task right after the callback instead of one setTimeout(fn, 0) later #3836
• Docs included?: no, the upgrade-guide entry lands on the rc.1 docs PR docs: document the 22.0.0-rc.1 changes #3835.
• Test units included?: yes
• Breaking change?: yes
• In a clean directory, yarn install, yarn test run successfully? yes, as npm ci and npm test

Description

Removes the pending task a callback-taking wrapper registers in a finally right after the callback body, and right after the unsubscribe call, instead of through setTimeout(taskDone, 0) in src/zones.ts. Deletes the 2021 TODO next to the wrapping call that asked for this.

• The finally runs whether the callback returns or throws, so a throwing callback does not leave its task behind, which the timer also guaranteed.
• This is the same way Angular's own pendingUntilEvent works: it forwards the value and then removes its task synchronously.
• Nothing else in the wrapper changes: the task is still registered at call time, the callback still runs inside the Angular zone and the injection context, and the Observable and Promise branches are untouched.

What this grants, measured on Angular 22.2 zone.js and zoneless apps, before and after:

• The task is gone before any setTimeout(fn, 0) callback registered at delivery, in every run: a synthetic callback in Chrome and Firefox, the unsubscribe path, and the real onSnapshot against the Firestore emulator. With Realtime Database on cached data, where the SDK invokes the callback inside the registering call, the task is removed inside that call.
• A zone.js server render reports stable about a millisecond sooner after a single callback read's first value. In a zoneless render the difference is within noise: the callback's own signal write already schedules Angular's tick, which bounds stability either way.
• In a zone.js app, a callback delivered inside the Angular zone no longer causes a third change-detection pass.

What does not change:

• The DOM updates on delivery, and the number of change-detection passes for a callback delivered from outside Angular.
• No task is left behind in the four callback cases probed for fix: stop twelve wrapped calls from holding the app unstable #3827 against the emulators.
• When whenStable() resolves under fake timers. Angular's change-detection tick is itself a timer, so a test that advances fake timers before awaiting whenStable() still needs the advance, before and after.

What upgrading apps may notice:

• whenStable() and server rendering follow a callback read's first value one setTimeout(fn, 0) delay sooner.
• A test that inspects pending tasks directly sees the wrapper's task gone as soon as the callback has run, without a timer advance.

Verification:

• Four new specs in src/zones.spec.ts, each observing the remover function PendingTasks.add() returns. All four fail on main and pass here:
  • the task is removed after the callback body and before any microtask the body queued, before a setTimeout(fn, 0) callback registered just before delivery
  • the same when the SDK invokes the callback inside the registering call
  • the same on unsubscribe
  • a throwing callback does not leave its task behind
• npm run lint, npm run test:node, npm run test:chrome-headless and npm run test:firefox-headless pass on the branch.

[tyler-reitz]

Requesting changes for one spec.

The unsubscribe spec passes even when the task is never released. Deleting taskDone() from the unsubscribe finally and rebuilding leaves karma at 142/142, because the 500ms fallback in observeRelease() resolves to the same all-false value that spec expects. The other three assert afterCallbackBody: true, which the fallback can't produce. Having the remover resolve with released: true and the fallback with released: false would separate the two.

Non-blocking: this conflicts with #3829 in src/zones.ts and src/zones.spec.ts. When resolving, I'd put #3829's injector.destroyed early return inside the new try, so a handler that runs after teardown still releases its task.

Otherwise checked: all four new specs fail against main's zones.ts, and the branch builds with no generated-file drift and passes 142/142 locally.

[armando-navarro]

Thanks for catching that, @tyler-reitz. Both points are in.

Unsubscribe spec

• Each recorded result now carries released, true from the remover and false from the 500 ms fallback, as you suggested.
• With taskDone() deleted from the unsubscribe finally, the unsubscribe spec now fails (Expected $.released = false to equal true.).

Merge with #3829

• The injector.destroyed early return sits inside the try, so a handler that runs after teardown still removes its task.
• A new spec covers it with a child environment injector, destroyed before the handler fires. With the early return moved outside the try, it fails in both change-detection modes.
• An app hits this only when an environment injector is destroyed while the app keeps running, such as route injectors under withAutoCleanupInjectors().
• fix(core): wrap observer-object handlers like functions, and let a wrapped promise settle after teardown #3829's spec comment about a 0 ms timer is reworded to match the new removal.