test(forms): reproduce stale debounced async validation results - #71637

Issue #71636 | Triage note | Forms spec | Core spec | Stuck fix #71414

Why the change

This adds failing specs showing that a debounced async validator keeps its old result instead of reporting pending right after a value change, so that we can agree on a fix in @angular/core before I write it.

Special things to note

• This PR is triage only: it changes no library code. Three of its four specs fail on purpose. I applied option A below temporarily: all four pass, and so do the core resource suites (Node, Chromium, Firefox) and the signal forms suites (Node, Chromium).
• fix(forms): safely chain debounced async validation resources #71414 is stuck. The review on Oct 25 requested changes, said that the gap isn't specific to signal forms because @angular/core has no snapshot-based chaining primitive, and objected to keeping the previous settled value while debouncing. Its author replied that it "seems to be unfixable without breaking changes or creating a new API". Option A follows the review: it removes the stale resolved state in core debounced() itself, for every chain(debounced(...)) user.
• Option A doesn't fix Validate async signal leaks resource internals #70884. It makes the Validate async signal leaks resource internals #70884 pattern throw as soon as the value changes instead of after effects run (measured). A snapshot-based chaining primitive, as the review suggests, would fix Validate async signal leaks resource internals #70884 and works together with option A.

Change outline

What this PR adds

packages/core/test/resource/debounce_status_spec.ts                # 2 failing specs: the root cause
packages/forms/signals/
├── test/node/validate_async_debounce_window.spec.ts               # 1 failing spec, 1 passing control spec
└── triage/debounce-pending-window.md                              # spec output, root cause, measurements, fix options

Where the stale state comes from

f().value.set('VALID')                       # the validator settled on 'INVALID' before
  validateAsync params                       → 'VALID'
  debounced(params, 50)
    linkedSignal computation                 # previous state exists, so it's kept: resolved 'INVALID'
    effect (runs later)                      # sets loading and starts the timer
  computed(() => ɵchain(debounced))          → 'INVALID', because chain() only throws while loading
  resource request                           # unchanged, so status stays resolved with the old result

State read in the same task as value.set('VALID'), today:

debounced status    resolved ('INVALID')
field pending()     false
field invalid()     true, the old result
submit()            the action doesn't run

After option A:

debounced status    loading (value 'INVALID')
field pending()     true
field invalid()     false
submit()            the action runs, as it does without debounce

Recommended fix: debounced() reports loading as soon as its source changes

 // packages/core/src/resource/debounce.ts, debounced()
+  const equal = options?.equal ?? Object.is;
+
   const state = linkedSignal<...>({
     source: () => { /* unchanged */ },
     computation: (res, previous) => {
-      // If we already have a state from the effect or a previous read, keep it!
-      // The effect is responsible for timing and state transitions.
       if (previous !== undefined) {
-        return previous.value;
+        // The effect owns timing, but a changed source is pending from the moment it changes.
+        const prev = previous.value;
+        if (!res.thrown && prev.status === 'resolved' && !equal(res.value, prev.value)) {
+          return {status: 'loading', value: prev.value};
+        }
+        return prev;
       }
       /* first evaluation unchanged */
     },
   });

   effect(() => {
     /* ...read the source, unchanged... */
     const currentState = untracked(state);
-    const equal = options?.equal ?? Object.is;
-    if (currentState.status === 'reloading' || currentState.status === 'loading') {
+    // Compare with the value being waited on, or else with the settled value.
+    if (active !== undefined) {
       if (equal(value, pendingValue!)) return;
     } else if (currentState.status === 'resolved') {
       if (equal(value, currentState.value!)) return;
     }

• The effect guard has to change. The state can now be loading before any wait has started. With the old guard, a source that changes to undefined, which forms uses when validation is skipped, would match pendingValue and stay loading forever.
• The fix is in core. Forms doesn't change. Any app that reads a chain(debounced(...)) resource right after a write gets loading as well.
• Synchronous waits. A wait function that returns undefined shows loading until effects flush. Templates don't see it.
• Validate async signal leaks resource internals #70884 throws sooner. For a snapshot-based factory over chain(debounced(...)), a read in the same task as the write throws LOADING with option A, and returns the stale value today. Both throw after TestBed.tick(). Factories built with resource() aren't affected.

Alternatives

Decisions for maintainers

1. debounced() contract. Should status() turn loading at the moment the source changes? The debounced() guide says that it "tells you whether a new value is still pending".
2. Order with Validate async signal leaks resource internals #70884. Should option A land on its own, so that the Validate async signal leaks resource internals #70884 pattern fails a little sooner but in the same way, or together with the snapshot-based chaining primitive from the fix(forms): safely chain debounced async validation resources #71414 review?
3. Synchronous waits. Is a brief loading state acceptable for a wait function that returns undefined? The alternative is to report loading only for a numeric wait, which leaves custom async wait functions with today's window.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features): failing repro specs. There is no fix yet.
• Docs have been added / updated (for bug fixes / features): not applicable until a fix lands.

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe: triage. Failing repro specs and a triage note, with no library changes.

Does this PR introduce a breaking change?

• Yes
• No