test(forms): reproduce unneeded field injectors in signal forms - #71626

Issue #71623 | Triage note | Failing specs

Why the change

This adds failing specs showing that signal form fields create injectors that nothing uses, so that we can agree on the scope of the fix before I write it.

Special things to note

• This PR is triage only: it changes no library code. Both specs fail on purpose. A fix should make them pass, and they then stay as regression tests.
• The specs count calls to Injector.create, which ties them to the implementation. I couldn't find a public signal for "this field has an injector".
• The recommended fix changes FieldNodeStructure.destroy(), which the host teardown triage (Signal forms: destroying a form's component doesn't destroy its fields, so async validation keeps running #71622) also changes. Either can land first.

Change outline

What this PR adds

packages/forms/signals/
├── test/node/field_injector_allocation.spec.ts   # 2 failing specs
└── triage/injector-allocation.md                 # spec output, root cause with links, fix options

Where the injector comes from

new FieldNode(...)
  metadataState.runMetadataCreateLifecycle()
    if the field has no metadata keys: return        # no rule, or validate() only
    runInInjectionContext(structure.injector, ...)   # the getter creates an R3Injector here
      for each metadata key
        if key.create: key.create(...)               # only managed keys, such as validateAsync()

cleanup sweep: a field was removed from the model
  structure.destroy()
    this.injector.destroy()                          # the getter creates an injector if there was none

Injector.create calls for a form over 50 array items, with one rule on each item, today:

no rule            0
validate()         0
required()        50
min()             50
debounce()        50
validateAsync()   50
remove 50 items without a rule: 50

After the recommended fix:

no rule            0
validate()         0
required()         0
min()              0
debounce()         0
validateAsync()   50
remove 50 items without a rule: 0

Recommended fix: enter an injection context only for managed keys

 // packages/forms/signals/src/field/metadata.ts, class FieldMetadataState
   runMetadataCreateLifecycle(): void {
     // ...early return and params-flag handling unchanged...
-      untracked(() =>
-        runInInjectionContext(this.node.structure.injector, () => {
-          for (const key of this.node.logicNode.logic.getMetadataKeys()) {
-            if (key.create) {
-              /* create the managed value */
-            }
-          }
-        }),
-      );
+      untracked(() => {
+        for (const key of logic.getMetadataKeys()) {
+          if (!key.create) {
+            continue;
+          }
+          // Only managed keys need the field's injector, so it's created here and nowhere else.
+          runInInjectionContext(this.node.structure.injector, () => {
+            /* create the managed value, unchanged */
+          });
+        }
+      });
   }

 // packages/forms/signals/src/field/structure.ts, class FieldNodeStructure
   destroy(): void {
-    this.injector.destroy();
+    this._injector?.destroy();
   }

• Same contract. A managed key's create still runs in the field's injection context, which is all the guide promises. Plain keys only build a computed().
• No other readers. Nothing else reads a field's injector. compatForm() children read the root's injector, and that read stays lazy.
• Cost. A field with several managed keys enters the injection context once per key instead of once.

Alternatives

Decisions for maintainers

1. Injection context scope. Do you want every field with metadata to keep an injection context, for example for planned features? Option A narrows it to managed keys, which matches what the guide documents.
2. How much this matters. One injector costs about 1.1 to 1.5 µs to create in Node, and I didn't measure memory. Is that worth a fix now, or should it wait for the lightweight scope?
3. Test style. Is counting Injector.create calls acceptable in a regression test, or would you prefer another check?

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