MudTextField: Fix double validation on blur (#7034)

[vernou]

Description

In the precedent PR #7996, we introduced a boolean "_validated" to know when the validation already occurred and to avoid multiple validation.

But "_validated" is set to true after the validation is finished. When the validation is async, it's possible to start multiple validation in parallel, before "_validated" is set to true.

Resolves #7034.

How Has This Been Tested?

I added a test that test when the validation is async.
The test fail without the fix.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[vernou]

@henon, this PR complements a precedent PR that you contribute.
Can you review this PR?

[mikes-gh]

@vernou Thanks for the PR. Your test is failing.

[henon]

OK, straight forward and simple. Change looks good.

I don't get why the test doesn't work on the CI, I guess it works locally?

To get an understanding why the test fails on the CI you could temporarily add some Console.WriteLines in key locations to figure out what happens and wheter or not this is a timing issue or not

[henon]

OK, straight forward and simple. Change looks good.

Hmm on second thought, wouldn't this prevent validation entirely because it is et before the call?

[vernou]

I don't get why the test doesn't work on the CI, I guess it works locally?

Yes, it's work locally. It's a parallelization problem and the check is done before the validation.
It's fixed.

Hmm on second thought, wouldn't this prevent validation entirely because it is et before the call?

No, because when _validated is set to true, nothing prevents validation :

_validated = true;
await base.ValidateValue();

[mikes-gh]

I am not sure we should be adding delays to make tests past.
@henon Shouldn't we be using WaitForAssertion of some state then run the check?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e5b8c80) 88.11% compared to head (8e79b38) 88.12%.
Report is 4 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #8121      +/-   ##
==========================================
+ Coverage   88.11%   88.12%   +0.01%     
==========================================
  Files         394      394              
  Lines       11760    11760              
  Branches     2384     2384              
==========================================
+ Hits        10362    10364       +2     
  Misses        871      871              
+ Partials      527      525       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vernou]

@mikes-gh
I agree, I don't like Task.Delay in a test. But I don't see how to do otherwise.

The first assert check the state has changed, so WaitForAssertion can be used.
But the second assert check the state didn't change, I don't know how avoid delay in this case.

I modified the test in this way.
If you know a better approach, I'm interested.

---

Also the test didn't work, because it didn't wait before to check the validation isn't called a second time.
It's fixed in the modification.

[vernou]

@henon, @mikes-gh
What is the next step?

[henon]

Thanks for the contribution @vernou and sorry, the PR slipped my mind.