Fix: Unique lock not being released after transaction rollback in ShouldBeUnique jobs with afterCommit() #55420
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.
This pull request addresses an issue where ShouldBeUnique jobs scheduled with
afterCommit()
would fail to execute after a transaction rollback.The problem occurred because when a ShouldBeUnique job is dispatched, a unique lock is created. Under normal circumstances, this lock is released after the job has been executed successfully. However, if the transaction within which the job was dispatched rolled back, the unique lock would remain in place. This would prevent any subsequent dispatch of the same ShouldBeUnique job from being processed, as the unique lock would still exist.
This pull request introduces a fix to ensure that when a transaction rollback occurs, any associated unique locks created by ShouldBeUnique jobs dispatched with
afterCommit()
are properly released. This ensures that the jobs can be dispatched and executed correctly even after a transaction rollback.e.g.