The load-bearing line in the whole trace is a `return undefined`. The computation that feeds the resource's params checks `validationState.shouldSkipValidation()` and `validationState.syncValid()`, and returns undefined when either says no [7]. A resource whose params computation returns undefined sits in `idle` and never calls its loader, because `loadEffect()` returns early the moment it sees `extRequest.request === undefined`, and that is documented public behaviour rather than a forms detail [8]. The docs promise that async validation runs only after all synchronous validation passes, and nobody in the forms code wrote that promise [9]. It falls out of a rule that shipped before the feature did.
That is why the file reads the way it does. In validate_http.ts, the line handing `httpResource` over as a factory is the only one doing anything HTTP-related; everything else naming HTTP is an import, a type or a doc comment [5]. Galassi says he went in expecting a few hundred lines of async bookkeeping and found a body that was a single call [15], which is the rare kind of disappointment worth having.
Four of the six layers pass work downward without adding anything [6][1]. The two that do add something are the two you should read before you commit. Debounce is composed rather than written: `debounced(() => params(), opts.debounce)`, then `computed(() => ɵchain(debouncedResource))`, then the factory call [12]. `debounced()` is public and still experimental [13]. `ɵchain` is the internal side of `ctx.chain()`; the file does export `chain()`, but it carries no `@publicApi` marker and is not surfaced on `@angular/core`'s public entry point, which is why the forms code reaches it through the prefixed alias [14]. So a stable API is resting on one experimental primitive and one internal alias [3].
For the deletion to be safe rather than merely shorter, a few things have to be true of your form. Your request has to be expressible as a function of the field's value, since that function becomes the params [2]. Your debounce policy has to be one millisecond number per field [2]. Your error handling has to fit two callbacks that map a response or an error into a validation error object [2]. And the guarantees you actually depend on have to be the ones in the contract: sync validators first, request held until they pass, `pending()` true in flight, previous call cancelled when the user types again [3].
Watch that last one. The three behaviours the trace attributes to validate_async.ts are the sync gate, the pending projection and the debounce composition [16], and the delegating wrapper itself contains no await, no subscription and no cancellation logic [4]. Cancel-on-retype is stated as contract [3]; it is implemented somewhere below the layer where the gating and the status switch live. If stale-response overwrite is the failure your bespoke code was built to prevent, that is the part to verify by reading, not by trusting the wrapper.
In my context, which is two uniqueness checks against internal endpoints and no retry UI, the port is a delete. Where your old glue encoded policy that the four contract guarantees do not name, keep the policy and drop the transport.
