build(deps): bump github.com/riverqueue/river from 0.11.4 to 0.13.0

[dependabot]

Bumps github.com/riverqueue/river from 0.11.4 to 0.13.0.

Release notes

Sourced from github.com/riverqueue/river's releases.

v0.13.0

⚠️ Version 0.13.0 removes the original advisory lock based unique jobs implementation that was deprecated in v0.12.0. See details in the note below or the v0.12.0 release notes.

Added

• A middleware system was added for job insertion and execution, providing the ability to extract shared functionality across workers. Both JobInsertMiddleware and WorkerMiddleware can be configured globally on the Client, and WorkerMiddleware can also be added on a per-worker basis using the new Middleware method on Worker[T]. Middleware can be useful for logging, telemetry, or for building higher level abstractions on top of base River functionality.

  Despite the interface expansion, users should not encounter any breakage if they're embedding the WorkerDefaults type in their workers as recommended. [PR #632](riverqueue/river#632).

Changed

• Breaking change: The advisory lock unique jobs implementation which was deprecated in v0.12.0 has been removed. Users of that feature should first upgrade to v0.12.1 to ensure they don't see any warning logs about using the deprecated advisory lock uniqueness. The new, faster unique implementation will be used automatically as long as the UniqueOpts.ByState list hasn't been customized to remove required states (pending, scheduled, available, and running). As of this release, customizing ByState without these required states returns an error. [PR #614](riverqueue/river#614).
• Single job inserts are now unified under the hood to use the InsertMany bulk insert query. This should not be noticeable to users, and the unified code path will make it easier to build new features going forward. [PR #614](riverqueue/river#614).

Fixed

• Allow river.JobCancel to accept a nil error as input without panicking. [PR #634](riverqueue/river#634).

v0.13.0-rc.1

⚠️ Version 0.13.0 removes the original advisory lock based unique jobs implementation that was deprecated in v0.12.0. See details in the note below or the v0.12.0 release notes.

Added

• A middleware system was added for job insertion and execution, providing the ability to extract shared functionality across workers. Both JobInsertMiddleware and WorkerMiddleware can be configured globally on the Client, and WorkerMiddleware can also be added on a per-worker basis using the new Middleware method on Worker[T]. Middleware can be useful for logging, telemetry, or for building higher level abstractions on top of base River functionality.

  Despite the interface expansion, users should not encounter any breakage if they're embedding the WorkerDefaults type in their workers as recommended. [PR #632](riverqueue/river#632).

Changed

• Breaking change: The advisory lock unique jobs implementation which was deprecated in v0.12.0 has been removed. Users of that feature should first upgrade to v0.12.1 to ensure they don't see any warning logs about using the deprecated advisory lock uniqueness. The new, faster unique implementation will be used automatically as long as the UniqueOpts.ByState list hasn't been customized to remove required states (pending, scheduled, available, and running). As of this release, customizing ByState without these required states returns an error. [PR #614](riverqueue/river#614).
• Single job inserts are now unified under the hood to use the InsertMany bulk insert query. This should not be noticeable to users, and the unified code path will make it easier to build new features going forward. [PR #614](riverqueue/river#614).

Fixed

• Allow river.JobCancel to accept a nil error as input without panicking. [PR #634](riverqueue/river#634).

v0.12.1

Changed

• 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](riverqueue/river#617).

Fixed

• Unique job changes from v0.12.0 / [PR #590](riverqueue/river#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](riverqueue/river#619).

v0.12.0

⚠️ Version 0.12.0 contains a new database migration, version 6. See documentation on running River migrations. If migrating with the CLI, make sure to update it to its latest version:

go install github.com/riverqueue/river/cmd/river@latest
</tr></table> 

... (truncated)

Changelog

Sourced from github.com/riverqueue/river's changelog.

[0.13.0] - 2024-10-07

⚠️ Version 0.13.0 removes the original advisory lock based unique jobs implementation that was deprecated in v0.12.0. See details in the note below or the v0.12.0 release notes.

Added

• A middleware system was added for job insertion and execution, providing the ability to extract shared functionality across workers. Both JobInsertMiddleware and WorkerMiddleware can be configured globally on the Client, and WorkerMiddleware can also be added on a per-worker basis using the new Middleware method on Worker[T]. Middleware can be useful for logging, telemetry, or for building higher level abstractions on top of base River functionality.

  Despite the interface expansion, users should not encounter any breakage if they're embedding the WorkerDefaults type in their workers as recommended. [PR #632](riverqueue/river#632).

Changed

• Breaking change: The advisory lock unique jobs implementation which was deprecated in v0.12.0 has been removed. Users of that feature should first upgrade to v0.12.1 to ensure they don't see any warning logs about using the deprecated advisory lock uniqueness. The new, faster unique implementation will be used automatically as long as the UniqueOpts.ByState list hasn't been customized to remove required states (pending, scheduled, available, and running). As of this release, customizing ByState without these required states returns an error. [PR #614](riverqueue/river#614).
• Single job inserts are now unified under the hood to use the InsertMany bulk insert query. This should not be noticeable to users, and the unified code path will make it easier to build new features going forward. [PR #614](riverqueue/river#614).

Fixed

• Allow river.JobCancel to accept a nil error as input without panicking. [PR #634](riverqueue/river#634).

[0.12.1] - 2024-09-26

Changed

• 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](riverqueue/river#617).

Fixed

• Unique job changes from v0.12.0 / [PR #590](riverqueue/river#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](riverqueue/river#619).

[0.12.0] - 2024-09-23

⚠️ Version 0.12.0 contains a new database migration, version 6. See documentation on running River migrations. If migrating with the CLI, make sure to update it to its latest version:

go install github.com/riverqueue/river/cmd/river@latest
river migrate-up --database-url "$DATABASE_URL"

If not using River's internal migration system, the raw SQL can alternatively be dumped with:

go install github.com/riverqueue/river/cmd/river@latest
river migrate-get --version 6 --up > river6.up.sql
river migrate-get --version 6 --down > river6.down.sql

The migration includes a new index. Users with a very large job table may want to consider raising the index separately using CONCURRENTLY (which must be run outside of a transaction), then run river migrate-up to finalize the process (it will tolerate an index that already exists):

ALTER TABLE river_job ADD COLUMN unique_states BIT(8);
</tr></table> 

... (truncated)

Commits

• 1009775 prepare v0.13.0 (#637)
• 2870fcc Bump the go-dependencies group with 2 updates (#636)
• 4167ed8 Tiny changelog fix up to link up a pull request (#606)
• ed32320 prepare v0.13.0-rc.1 (#635)
• 0b93275 Add middleware system for jobs (#632)
• 4876b52 fix river.JobCancel with nil arg (#634)
• 5dd7f7c proof out a "pilot" layer between Client and Driver (#627)
• 0aa276d remove deprecated advisory lock uniqueness, consolidate insert logic (#614)
• 183f359 go work sync && make tidy (#624)
• bb8997e prepare v0.12.1 (#620)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #531.