Releases: riverqueue/river
v0.10.1
v0.10.0
go install github.com/riverqueue/river/cmd/river@latest
river migrate-up --database-url "$DATABASE_URL"
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_key bytea;
CREATE UNIQUE INDEX CONCURRENTLY river_job_kind_unique_key_idx ON river_job (kind, unique_key) WHERE unique_key IS NOT NULL;
go install github.com/riverqueue/river/cmd/river@latest
river migrate-up --database-url "$DATABASE_URL"
Added
- Fully functional driver for
database/sql
for use with packages like Bun and GORM. PR #351. - Queues can be added after a client is initialized using
client.Queues().Add(queueName string, queueConfig QueueConfig)
. PR #410. - Migration that adds a
line
column to theriver_migration
table so that it can support multiple migration lines. PR #435. --line
flag added to the River CLI. PR #454.
Changed
v0.9.0
Added
Config.TestOnly
has been added. It disables various features in the River client like staggered maintenance service start that are useful in production, but may be somewhat harmful in tests because they make start/stop slower. PR #414.
Changed
ErrorHandler
. As before, we try never to make breaking changes, but this one was deemed quite important because ErrorHandler
was fundamentally lacking important functionality.
-
Breaking change: Add stack trace to
ErrorHandler.HandlePanicFunc
. Fixing code only requires adding a newtrace string
argument toHandlePanicFunc
. PR #423.# before HandlePanic(ctx context.Context, job *rivertype.JobRow, panicVal any) *ErrorHandlerResult # after HandlePanic(ctx context.Context, job *rivertype.JobRow, panicVal any, trace string) *ErrorHandlerResult
Fixed
- Pausing or resuming a queue that was already paused or not paused respectively no longer returns
rivertype.ErrNotFound
. The same goes for pausing or resuming using the all queues string (*
) when no queues are in the database (previously that also returnedrivertype.ErrNotFound
). PR #408. - Fix a bug where periodic job constructors were only called once when adding the periodic job rather than being invoked every time the periodic job is scheduled. PR #420.
v0.8.0
0.7.0
Added
- The default max attempts of 25 can now be customized on a per-client basis using
Config.MaxAttempts
. This is in addition to the ability to customize at the job type level withJobArgs
, or on a per-job basis usingInsertOpts
. PR #383. - Add
JobDelete
/JobDeleteTx
APIs onClient
to allow permanently deleting any job that's not currently running. PR #390.
Fixed
- Fix
StopAndCancel
to not hang if called in parallel to an ongoingStop
call. PR #376.
v0.6.1
Fixed
- River now considers per-worker timeout overrides when rescuing jobs so that jobs with a long custom timeout won't be rescued prematurely. PR #350.
- River CLI now exits with status 1 in the case of a problem with commands or flags, like an unknown command or missing required flag. PR #363.
- Fix migration version 4 (from 0.5.0) so that the up migration can be re-run after it was originally rolled back. PR #364.
v0.6.0
Added
RequireNotInserted
test helper (in addition to the existingRequireInserted
) that verifies that a job with matching conditions was not inserted. PR #237.
Changed
- The periodic job enqueuer now sets
scheduled_at
of inserted jobs to the more precise time of when they were scheduled to run, as opposed to when they were inserted. PR #341.
Fixed
- Remove use of
github.com/lib/pq
, making it once again a test-only dependency. PR #337.
v0.5.0
Added
-
Add
pending
job state. This is currently unused, but will be used to build higher level functionality for staging jobs that are not yet ready to run (for some reason other than their scheduled time being in the future). Pending jobs will never be run or deleted and must first be moved to another state by external code. PR #301. -
Queue status tracking, pause and resume. PR #301.
A useful operational lever is the ability to pause and resume a queue without shutting down clients. In addition to pause/resume being a feature request from #54, as part of the work on River's UI it's been useful to list out the active queues so that they can be displayed and manipulated.
A new
river_queue
table is introduced in the v4 migration for this purpose. Upon startup, every producer in each RiverClient
will make anUPSERT
query to the database to either register the queue as being active, or if it already exists it will instead bump the timestamp to keep it active. This query will be run periodically in each producer as long as theClient
is alive, even if the queue is paused. A separate query will delete/purge any queues which have not been active in awhile (currently fixed to 24 hours).QueuePause
andQueueResume
APIs have been introduced toClient
pause and resume a single queue by name, or all queues using the special*
value. Each producer will watch for notifications on the relevantLISTEN/NOTIFY
topic unless operating in poll-only mode, in which case they will periodically poll for changes to their queue record in the database.
Changed
-
Job insert notifications are now handled within application code rather than within the database using triggers. PR #301.
The initial design for River utilized a trigger on job insert that issued notifications (
NOTIFY
) so that listening clients could quickly pick up the work if they were idle. While this is good for lowering latency, it does have the side effect of emitting a large amount of notifications any time there are lots of jobs being inserted. This adds overhead, particularly to high-throughput installations.To improve this situation and reduce overhead in high-throughput installations, the notifications have been refactored to be emitted at the application level. A client-level debouncer ensures that these notifications are not emitted more often than they could be useful. If a queue is due for an insert notification (on a particular Postgres schema), the notification is piggy-backed onto the insert query within the transaction. While this has the impact of increasing insert latency for a certain percentage of cases, the effect should be small.
Additionally, initial releases of River did not properly scope notification topics within the global
LISTEN/NOTIFY
namespace. If two River installations were operating on the same Postgres database but within different schemas (search paths), their notifications would be emitted on a shared topic name. This is no longer the case and all notifications are prefixed with a{schema_name}.
string. -
Add
NOT NULL
constraints to the database forriver_job.args
andriver_job.metadata
. Normal code paths should never have allowed for null values any way, but this constraint further strengthens the guarantee. PR #301. -
Stricter constraint on
river_job.finalized_at
to ensure it is only set when paired with a finalized state (completed, discarded, cancelled). Normal code paths should never have allowed for invalid values any way, but this constraint further strengthens the guarantee. PR #301.
v0.4.1
v0.4.0
- Breaking change: There are a number of small breaking changes in the job list API using
JobList
/JobListTx
:- Now support querying jobs by a list of Job Kinds and States. Also allows for filtering by specific timestamp values. Thank you Jos Kraaijeveld (@thatjos)! 🙏🏻 PR #236.
- Job listing now defaults to ordering by job ID (
JobListOrderByID
) instead of a job timestamp dependent on on requested job state. The previous ordering behavior is still available withNewJobListParams().OrderBy(JobListOrderByTime, SortOrderAsc)
. PR #307. - The function
JobListCursorFromJob
no longer needs a sort order parameter. Instead, sort order is determined based on the job list parameters that the cursor is subsequently used with. PR #307.
- Breaking change: Client
Insert
andInsertTx
functions now return aJobInsertResult
struct instead of aJobRow
. This allows the result to include metadata like the newUniqueSkippedAsDuplicate
property, so callers can tell whether an inserted job was skipped due to unique constraint. PR #292. - Breaking change: Client
InsertMany
andInsertManyTx
now return number of jobs inserted asint
instead ofint64
. This change was made to make the type in use a little more idiomatic. PR #293. - Breaking change:
river.JobState*
type aliases have been removed. All job state constants should be accessed throughrivertype.JobState*
instead. PR #300.
See also the 0.4.0 release blog post with code samples and rationale behind various changes.