Signal forms: compatForm() fields ignore parse errors, so submit() sends the last valid value #71633

Which @angular/* package(s) are the source of the bug?

forms

Is this a regression?

No

Description

In short. When a compatForm() field is bound with [formField] to a control that can't parse
what the user typed, the field ignores the parse error. For example, <input type="number"> with
30e in it. The field stays valid, no error shows, and submit() runs with the last value that
parsed. The same template on a plain form() field blocks the submit.

Why it matters. compatForm() is the documented way to migrate a reactive form to signal forms
step by step, and the migration guide
binds compat fields with [formField]. The failure is silent: the user sees one value, and the app
saves another.

Failure mode in user code.

@Component({
  imports: [FormField],
  template: `
    <input type="number" [formField]="f.age" />
    @if (f.age().invalid()) {
      <p>Enter a valid age.</p>
    }
    <button (click)="save()">Save</button>
  `,
})
export class Profile {
  readonly model = signal({age: new FormControl(30, {nonNullable: true})});
  readonly f = compatForm(this.model);

  save() {
    submit(this.f, async () => {
      await saveProfile({age: this.model().age.value});
    });
  }
}

Starting state: the FormControl value is 30, the input shows 30, f.age().errors() is [],
and f.age().invalid() is false.

Current behavior:

1. User types "30e"   input shows "30e"; FormControl value stays 30
                      f.age().errors()  → []
                      f.age().invalid() → false
                      no error message
2. User clicks Save   the action runs and saves {age: 30}

Expected behavior:

1. User types "30e"   input shows "30e"; FormControl value stays 30
                      f.age().errors()  → [{kind: 'parse', ...}]
                      f.age().invalid() → true
                      "Enter a valid age." shows
2. User clicks Save   the action doesn't run

Assumptions: expected vs current.

Affected areas.

• CompatValidationState in packages/forms/signals/compat/src/compat_validation_state.ts:
  parseErrors, errors, syncValid, valid, and invalid.
• Every source of parse errors, on a compat field:
  • Native inputs with bad input, such as number, date, and time.
  • Legacy NG_VALIDATORS on a CVA, which are shimmed into parse errors.
  • Custom controls that report parseErrors.
• submit() on a compat root, and on a plain root with compat children.
• The migration guide's statements that reactive state is proxied and that errors() returns
  CompatValidationError.

Tradeoffs of the fix.

• After the fix, f.age().invalid() is true while the FormControl and its parent FormGroup
  still report valid. Parse errors live in the signal-forms layer, so reactive code that checks
  formGroup.valid disagrees with submit().
• Writing parse errors into the FormControl with setErrors() would avoid that split, but the next
  updateValueAndValidity() wipes them, and it fights reactive forms' ownership of the control.
• errors() would mix CompatValidationError with parse errors, which have no control or
  context. The public type doesn't change, and the guide's errorMessage() helper on main
  already falls back to error.message ?? error.kind.
• Only documenting the limitation is cheapest, but it leaves a silent submit with the wrong value.

For comparison, the two APIs that compat bridges both catch this case. Reactive forms'
NumberValueAccessor writes null for bad input, so Validators.required fails. Plain signal
forms block the submit.

Related bug, same file. A compat field's errorSummary is always empty, so the root's
errorSummary() omits every FormControl error: #71634.

Details.

• Triage PR with the recommended fix, design decisions, and questions: test(forms): add repro specs for compat parse errors #71628
• Triage notes:
  observed output, root cause, and history.
• CompatValidationState,
  FieldValidationState.parseErrors and errors,
  FormField.errors,
  submit() gate,
  errorMessage() in the guide on main.

Please provide a link to a minimal reproduction of the bug

compat_parse_errors.spec.ts
in the triage PR. The repro spec asserts the expected behavior and fails today. The web test
runner ignores --filter, so this runs the whole Chromium suite:

pnpm bazel test //packages/forms/signals/test/web:test_chromium --test_output=all

Please provide the exception or error you saw

No error is thrown. The repro spec reports:

Expected $.fieldErrors.length = 0 to equal 1.
Expected $.fieldInvalid = false to equal true.
Expected $.rootInvalid = false to equal true.
Unexpected $.actionSaw[0] = 5 in array.

Please provide the environment you discovered this bug in (run ng version)

angular/angular main at ce30bb0889 (2026-10-16), Bazel target
//packages/forms/signals/test/web:test_chromium. The affected source files are unchanged on main at
3e173fc844 (2026-10-24). Native inputs have produced parse errors since v22.0.0-next.0.

Anything else?

I searched for an existing issue or PR and found none.