Fix ValidatableTypeInfo to skip IValidatableObject validation when property validation fails

[Copilot]

The current minimal API validation logic runs IValidatableObject validation even when property-level validation fails, which is inconsistent with the behavior of System.ComponentModel.DataAnnotations.Validator. This creates a breaking change for Blazor apps that opt into the new validation support.

Problem

The original System.ComponentModel.DataAnnotations.Validator behavior stops validation if there are any property-level validation errors, as object-level validation may rely on properties already being valid. The new validation implementation was running both property and object-level validation regardless of property validation failures.

Solution

This PR updates the ValidatableTypeInfo implementation to align with the original System.ComponentModel.DataAnnotations behavior:

1. Separate validation phases: Property attribute validation now runs before IValidatableObject validation
2. Track property validation errors: The implementation tracks whether property-level validation fails
3. Skip IValidatableObject when needed: If property validation fails, IValidatableObject validation is skipped
4. Maintain validation order: The correct order is now: property attributes → complex objects → sub-types → IValidatableObject (only if no property errors)

Changes Made

• Modified ValidatableTypeInfo.ValidateAsync to separate property validation from object validation
• Added ValidatePropertyAttributesAsync and ValidateComplexObjectsAsync methods to ValidatablePropertyInfo
• Updated existing tests to reflect the correct behavior
• Added a test case to verify IValidatableObject validation is skipped when property validation fails

Example

public class TestModel : IValidatableObject
{
    [Required]
    public string Name { get; set; } = "";

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        // This will NOT be called if Name is empty (property validation fails)
        // Previously, this would still be called
        yield return new ValidationResult("Custom validation error");
    }
}

All tests pass, confirming the fix maintains backward compatibility while aligning with the expected validation behavior.

Fixes #62584.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[dotnet-policy-service]

Greetings human! You've submitted a PR that modifies code that is shared with https://github.com/dotnet/runtime . Please make sure you synchronize this code with the changes in that repo!

[captainsafia]

@copilot Looks good! One piece of feedback to address.

[javiercn]

@copilot add a test like the following.

public class Address : IValidatableObject
{
    [MinLength(5)]
    public string Street { get; set; }

    public bool WasValidateCalled { get; private set; }

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        WasValidateCalled = true;
        yield return new ValidationResult("Address-level validation ran.");
    }
}

[Fact]
public async Task DoesNotCallObjectValidation_WhenPropertyAttributeValidationFails()
{
    // Arrange
    var address = new Address { Street = "123" }; // Too short for MinLength(5)
    var context = new ValidationContext(address);
    var results = new List<ValidationResult>();

    // Act
    var isValid = Validator.TryValidateObject(address, context, results, validateAllProperties: true);

    // Assert
    Assert.Contains(results, r => r.ErrorMessage.Contains("minimum length of '5'"));
    Assert.DoesNotContain(results, r => r.ErrorMessage == "Address-level validation ran.");
    Assert.False(address.WasValidateCalled);
}

[Copilot]

Added the test demonstrating the expected behavior using System.ComponentModel.DataAnnotations.Validator. The test verifies that IValidatableObject.Validate is not called when property validation fails, which matches the standard .NET validation behavior. (0934867)

[javiercn]

@copilot
Why are you ignoring the result here. The way the code is structured makes it seem as if you are running the object validation independent of whether the property validation failed.

[Copilot]

I was ignoring the result to maintain the current behavior where complex object validation always runs regardless of property validation results. Complex object validation automatically handles null values and non-null objects should still be validated even if they fail property-level validation. I've clarified this intention with an explicit discard and comment explaining the rationale. (3e8c7fb)

[javiercn]

I disagree

If any of the properties fails validation that itself might cause additional validation errors in the object independent of whether or not the property is null.

Compare your implementation to TryValidateObject in System.ComponentModel, the behavior should match

[Copilot]

You're absolutely right. I've updated the implementation to match System.ComponentModel.DataAnnotations.Validator behavior. Now complex object validation only runs if property validation succeeds, aligning with the standard .NET validation pattern where any property validation failure stops further validation. (e87c7fb)