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

forms

Is this a regression?

No

Description

We've come across to what I think is a bug in form validation in reactive forms. Stackblitz is kind of self-explanatory, but to sum it up, when creating FormControl (that is not visible right away on the view), validation works differently depending on how validators are passed onto the control (simple validator vs array of validators).

If you open the stackblitz, and right away click on the buttons you'll see that one of the forms shows an alert and the other doesn't. The only difference between these two is the validatorOrOpts param used to create the controls.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-378jka?file=src%2Fmain.ts

Please provide the exception or error you saw

Both forms should either be valid or invalid (based on the expected behaviour from the Angular team) instead of varying based on how the ValidatorFn are passed.

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

Angular CLI: 17.1.2
Node: 18.18.0
Package Manager: npm 10.2.3
OS: linux x64

Angular: 17.1.2
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1701.2
@angular-devkit/build-angular   17.1.2
@angular-devkit/core            17.1.2
@angular-devkit/schematics      17.1.2
@schematics/angular             17.1.2
rxjs                            7.8.1
typescript                      5.3.3
zone.js                         0.14.3

Anything else?

After further testing looks like changing the validator's return from

  static test(control: AbstractControl): ValidationErrors | null {
    return {
      ...Validators.maxLength(10)(control),
    };
  }

to

  static test(control: AbstractControl): ValidationErrors | null {
    return Validators.maxLength(10)(control);
  }

solves the issue, but looks like a random difference in validation :/

In our case we're using the first to return all the errors in one (as we have some complex validators that might need of all the errors to properly build feedback for the user).