[9.x] Ensure freezeUuids always resets UUID creation after exception in callback #44018
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If merged, #44013 should be closed.
Please see #44013 for details on the problem this PR is solving.
This PR is a slightly different implementation of #44013 using the existing method as per the recommendation from @timacdonald #44013 (comment).
Instead of messy commits I thought 2 separate PRs would be cleaner.
Only one of them should be merged.
Recently I ran into an issue using the new
createUuidsUsing
method introduced in #42619.The issue caused most of my test suite to fail due to one test failing.
This is because I use
Str::uuid()
to generate UUIDs for my models and I was getting a heap of duplicates. The underlying cause being that when my initial test failed,Str::createUuidsNormally()
was never being called to essentially clean up from an exception/failed assertion that I was not expecting to be thrown.Then when running the test in isolation, it works fine. I don't think failures in previous tests should cause all of your test suite to fail.
So as an example, both tests below would fail;
This then caused hundreds of tests to fail. With this new PR, when considering the following example, the first test will fail (as expected) however the second test will pass.
I believe similar logic would already apply to methods like
Event::fakeFor()
where failures within that closure would not affect additional tests.