You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #590 introduced a more flexible unique job mechanism that allowed for the
unique states to be customized, all while still benefiting from the performance
improvements of using a unique index rather than an advisory lock. The retryable
state is included in the default list of states, but can be removed if the user
doesn't want to prevent an erroring job from blocking duplicate inserts.
However this created an issue: when trying to schedule a retryable job (move it
to available) it could potentially have a conflict with a duplicate unique job.
To handle this, special logic was added to try to deal with this scenario for
unique jobs, moving the conflicting row to discarded rather than available.
Unfortunately this logic had issues and was insufficiently tested. There were a
couple specific scenarios that caused issues:
A unique job that was being scheduled because it was either inserted as
scheduled or had errored and become retryable would actually be considered a
conflict with itself because the query didn't properly exclude the row being
scheduled. Attempting to schedule two duplicate retryable unique jobs at the
same time would lead to a unique conflict because there was no mechanism to
prevent this. The query changes in this PR address both of the above cases
along with test coverage.
The increased complexity is unfortunate, and we're probably nearing the limit of
what should be dealt with in a single SQL query. If this still isn't complete
I'm more inclined to fix the issues by catching these conflicts at the
application level, explicitly moving the conflicting row(s) to discarded, and
trying again. This can be looped with a backoff or recursed to ensure that
progress keeps being made as individual conflicts get resolved. But hopefully
that won't be necessary.
Fixes#618.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
11
11
12
12
- The `BatchCompleter` that marks jobs as completed can now batch database updates for _all_ states of jobs that have finished execution. Prior to this change, only `completed` jobs were batched into a single `UPDATE` call, while jobs moving to any other state used a single `UPDATE` per job. This change should significantly reduce database and pool contention on high volume system when jobs get retried, snoozed, cancelled, or discarded following execution. [PR #617](https://github.com/riverqueue/river/pull/617).
13
13
14
+
### Fixed
15
+
16
+
- Unique job changes from v0.12.0 / [PR #590](https://github.com/riverqueue/river/pull/590) introduced a bug with scheduled or retryable unique jobs where they could be considered in conflict with themselves and moved to `discarded` by mistake. There was also a possibility of a broken job scheduler if duplicate `retryable` unique jobs were attempted to be scheduled at the same time. The job scheduling query was corrected to address these issues along with missing test coverage. [PR #619](https://github.com/riverqueue/river/pull/619).
17
+
14
18
## [0.12.0] - 2024-09-23
15
19
16
20
⚠️ Version 0.12.0 contains a new database migration, version 6. See [documentation on running River migrations](https://riverqueue.com/docs/migrations). If migrating with the CLI, make sure to update it to its latest version:
0 commit comments