Skip to content
River Docs

River Pro Changelog

All notable changes to this project will be documented in this file.

[v0.24.0-rc.1] - 2026-05-07

⚠️ v0.24.0 contains new database migrations for the pro line, versions 6 and 7, to support a more scalable and feature-rich workflow engine.

These migrations are intended to be rolled out in two phases in production:

  • Migration v6 is the compatibility step. It adds new workflow-specific tables, adds workflow_id and workflow_task columns on river_job and river_job_dead_letter, as well as indexes to support more efficient workflow queries and to enforce task name uniqueness within a workflow. On river_job, these columns are auto-populated by a trigger. Both tables are backfilled in the migration.

    • Migration v6 also performs some non-workflow maintenance as well: if river_job.partition_key exists as a generated column, it's rebuilt to be a standard column with triggers instead. We've found the latter to have more predictable performance and operational properties, particularly for initial onboarding in large River installations.

  • Migration v7 is the cleanup step. It removes legacy workflow indexes that older River Pro nodes still rely on for efficient queries. Once run, older workflow queries will be much less efficient.

Run v6 first, deploy v0.24.0 to all River Pro nodes, and run v7 only after the rollout is complete. These migrations are safely reversible until you start using new workflow features like signals and timers, after which reversing v6 will drop newly introduced workflow state. They also involve heavy table rewrites.

Simple migration (suitable for most systems)

⚠️ Migration v6 can take significant time on large river_job tables because it includes a full backfill and several non-concurrent index builds. Most installations should run the migration as-is. If your river_job table is very large and you need to stage the expensive work more carefully, see the advanced migration below.

If migrating with the CLI, update it first, then use this production rollout sequence:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest


# Step 1: apply only migration v6.
riverpro migrate-up --database-url "$DATABASE_URL" --line pro --target-version 6 --max-steps 1


# === DEPLOY BREAKPOINT ===
# Deploy this River Pro release to all instances.
# Wait for rollout completion and verify system health.
# Older releases still rely on legacy workflow indexes, so do not run v7 until every River Pro node is on v0.24.0.


# Step 2: apply only migration v7 after all nodes are on this release.
riverpro migrate-up --database-url "$DATABASE_URL" --line pro --target-version 7 --max-steps 1

If not using River's internal migration system, or if you want to inspect or split the SQL yourself, dump the migration files with:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-get --version 6 --line pro --up > river-pro-v6.up.sql
riverpro migrate-get --version 6 --line pro --down > river-pro-v6.down.sql
riverpro migrate-get --version 7 --line pro --up > river-pro-v7.up.sql
riverpro migrate-get --version 7 --line pro --down > river-pro-v7.down.sql

Advanced migration (for large scale or high-throughput systems)

All of the steps in the v6 migration are idempotent and can be safely run in advance to better control the workload on a large system. These specific steps in particular are heavy and can impact a production system:

  • Adding new indexes to river_job without using CREATE INDEX CONCURRENTLY to avoid blocking the table.
  • Backfilling the new materialized workflow columns on river_job, which will rewrite all workflow jobs in the table to populate those columns.

To safely perform these steps manually in advance of the actual migration rollout:

  1. Check for duplicate workflow task names:

    SELECT metadata->>'workflow_id' AS workflow_id, metadata->>'task' AS workflow_task, COUNT(*) AS duplicate_count, ARRAY_AGG(id ORDER BY id) AS job_ids
    FROM river_job
    WHERE metadata->>'workflow_id' IS NOT NULL AND metadata->>'task' IS NOT NULL
    GROUP BY 1, 2
    HAVING COUNT(*) > 1
    ORDER BY duplicate_count DESC, workflow_id, workflow_task;

    If this returns any rows, resolve those duplicates before proceeding.

  2. Dump the v6 migration with:

    Terminal window
    riverpro migrate-get --version 6 --line pro --up > river-pro-v6.up.sql

    Any of its steps can be run in advance, but the most important ones are outlined below.

  3. Add the new workflow_id and workflow_task columns to river_job in an initial empty state.

  4. After those columns exist, backfill river_job in batches if needed. The migration's built-in backfill will skip rows that are already populated:

    DO $$
    DECLARE
      rows_updated int;
    BEGIN
      LOOP
        UPDATE river_job
        SET
          workflow_task = metadata->>'task',
          workflow_id = metadata->>'workflow_id'
        WHERE id IN (
          SELECT id FROM river_job
          WHERE (workflow_task IS NULL AND metadata->>'task' IS NOT NULL)
             OR (workflow_id IS NULL AND metadata->>'workflow_id' IS NOT NULL)
          LIMIT 10000 -- update a max of 10000 jobs per operation
          FOR UPDATE SKIP LOCKED
        );
        GET DIAGNOSTICS rows_updated = ROW_COUNT;
        EXIT WHEN rows_updated = 0;
        PERFORM pg_sleep(0.1); -- wait 0.1 seconds between queries to give the DB some breathing room.
      END LOOP;
    END $$;

    This commmand can be safely interrupted and re-run as needed, picking up where it left off.

  5. Build the v6 indexes concurrently if you want to avoid the migration's default non-concurrent index creation. Do this by taking the CREATE INDEX statements from river-pro-v6.up.sql, changing them to CREATE INDEX CONCURRENTLY IF NOT EXISTS, and running them outside a transaction. This only needs to be done in advance for the indexes on the busy river_job table.

  6. Finish by running migration v6 normally. Its conditional backfill and IF NOT EXISTS clauses will skip work that you already staged.

Changed

  • river.partition_key becomes a non-generated column whose value is updated via triggers instead. We've found this setup to be more predictable from a performance and operational standpoint. PR #297.

[v0.23.2] - 2026-04-20

Fixed

  • Removed accidentally left in replace directives in cmd/riverpro/go.mod.

[v0.23.1] - 2026-04-20

Changed

  • Updated River dependency to be compatible with v0.35.0. PR #298.

v0.23.0 - 2026-03-23

Added

  • Added WorkflowT.LoadTask and WorkflowT.LoadTaskTx methods for loading a single named task from a workflow without loading the full task set first.

Fixed

  • Event-driven workflow staging no longer blocks on row-lock contention in a way that could leave ready tasks pending and make workflows appear stuck until the statement exited or a later backstop pass ran. The event processor now uses non-blocking lock acquisition and performs one targeted retry for workflows that had ready tasks skipped due to contention, while the supervisor/backstop path keeps its bounded blocking behavior.
  • Sequence jobs no longer become runnable twice after a race, stalled sequences keep their retry signal when promotion loses that race, canceling a sequence job now advances the next job only when the sequence should continue, and the startup scan recovers locked heads instead of stalling behind them.
  • riverpropgxv5 now adapts JSON parameters for simple protocol / exec query modes so []byte JSON payloads are not encoded as bytea in pgx text-mode execution paths. This fixes invalid JSON syntax errors when running through protocol-constrained setups like PgBouncer transaction pooling while preserving normal behavior for explicit bytea parameters. Fixes riverqueue/river#1153.

v0.22.0 - 2026-02-21

Changed

  • Set minimum Go version to Go 1.25.
  • Upgrade River dependency to v0.31.0.

Fixed

  • Workflow task staging could attempt to revert jobs that had been concurrently finalized to available/scheduled and violate the finalized_or_finalized_at_null constraint. While this did not risk any corruption, incorrect workflow progression, or prolonged stalls, it could cause errors that would be resolved upon retry. To avoid this, workflow task staging now re-checks pending/finalized_at in its UPDATE predicate. Test coverage was added to confirm behavior with concurrent finalization.
  • NewClient no longer mutates caller-provided *Config values while assembling internal client configuration (including queue merge and Pro hook/middleware wiring).

v0.21.0 - 2026-01-12

Fixed

  • Struct tags for sequences (river:"sequence") and batches (river:"batch") now recurse into substructs on properties or which are embedded.

v0.20.0 - 2025-12-22

Added

  • Added FetchCooldown and FetchPollInterval settings to riverpro.QueueConfig to mirror the per-queue settings in OSS river.QueueConfig.

Changed

  • Update river dependency to v0.29.0.

0.19.0 - 2025-10-07

Added

  • Run many similar jobs at once with the new batching feature. Batches can wait for a configurable amount of time to try to fetch a full batch before executing all fetched jobs at the same time with WorkMany. See the docs for riverbatch or on the website for more details on how to get started with batching.

Changed

  • Increased job fetch timeout to 30 seconds. A recent change in v0.17.0 set this timeout to a fixed value but the value chosen was 2 seconds—it should have been higher.

0.18.0 - 2025-09-14

Added

  • Added Retry and RetryTx methods to the WorkflowT[TTx] type to allow multiple tasks in a workflow to be scheduled for retry. By default, all jobs will be retried. This can be overridden with the Mode option to retry only failed tasks to be retried.
  • Added WorkflowTaskWithDeps.Output to easily decode the output from an already-loaded workflow task.
  • Addd ephemeral queues feature. Entire queues can now be made ephemeral as opposed to only individual jobs.

Changed

  • Set minimum Go version to Go 1.24.

0.17.0 - 2025-09-04

This release adds new APIs for loading workflow tasks and decoding their output. From within a workflow task, it's now easy to grab all of the job's dependencies with LoadDeps / LoadDepsTx (recursively if needed) in order to inspect their output. It's also easy to load all tasks in a workflow if needed using LoadAll / LoadAllTx.

⚠️ Version v0.17.0 deprecates some existing workflow APIs as part of the new workflow task loading APIs. There is no immediate need to update existing working code and these deprecated APIs will be maintained at least until the v1 release. That said, migrating should be trivial for most apps and will unlock access to new workflow features. See the detailed notes below.

Added

  • Added WorkflowT[TTx] type which embeds a riverpro.Client to facilitate loader methods that require a database. This turned out to be much cleaner than passing a lot of state to the client methods for each of these calls and should provide more flexibility for upcoming features.

  • Added WorkflowT.LoadAll and WorkflowT.LoadAllTx methods for loading all tasks in a workflow, with support for pagination via WorkflowLoadAllOpts.

  • Added WorkflowT.LoadDeps, WorkflowT.LoadDepsTx, WorkflowT.LoadDepsByJob, and WorkflowT.LoadDepsByJobTx methods for loading direct or recursive dependencies of a workflow task using WorkflowLoadDepsOpts.

  • Added WorkflowT.LoadOutput, WorkflowT.LoadOutputTx, WorkflowT.LoadOutputByJob, and WorkflowT.LoadOutputByJobTx methods for loading and unmarshaling the output of a completed workflow task.

  • Introduced WorkflowTasks struct to expose collections of loaded workflow tasks, with methods like Get, Count, Names, and Output.

Changed

  • Increased number of fetch attempts when encountering expected transaction collision errors on concurrency-limited queues, and also switched from a constant backoff interval to an increasing one after the first few attempts.
  • Use a fixed timeout on job fetch attempts instead of one that starts low and increases. This should result in fewer visible context timeouts on fetch when the database is under high load.

Fixed

  • When fetching jobs, avoid taking a lock for concurrency limiting if concurrency limits are not enabled. This restores job throughput for non-Pro queues and Pro queues without global concurrency limits.

Deprecated

  • As part of the introduction of workflow task loaders and to allow for upcoming additions, we decided to deprecate the existing Workflow type along with several related workflow APIs (NewWorkflow, WorkflowFromExisting, WorkflowPrepare, WorkflowPrepareTx) in favor of new transactional variants accessible through Client.NewWorkflow and methods on WorkflowT. The Workflow type is now an alias to WorkflowT[any], and any of its new loader methods will not function unless it was loaded through a Client with a proper TTx type.

    Migrating to the new APIs is straightforward, though they require an available riverpro.Client:

    • Calls to riverpro.NewWorkflow should be updated to client.NewWorkflow.
    • Calls to riverpro.WorkflowFromExisting should be updated to client.WorkflowFromExisting.
    • Calls to riverClient.WorkflowPrepare(ctx, workflow) should be updated to workflow.Prepare(ctx).
    • Calls to riverClient.WorkflowPrepareTx(ctx, tx, workflow) should be updated to workflow.PrepareTx(ctx, tx).

    These deprecated APIs will be maintained at least until a v1 release.

0.16.0 - 2025-08-16

⚠️ Internal APIs used for communication between River and River Pro have changed. Make sure to update River and River Pro to latest at the same time to get compatible versions. River Pro v0.16 is compatible with River v0.24.

⚠️ Version v0.16.0 contains a new database migration for the pro line, version 4. This migration adds a new river_job_dead_letter table that's technically only necessary if using v0.16.0's new dead letter queue feature, but it's good practice to keep the pro schema as current as possible. If migrating with the CLI, make sure to update it to its latest version:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-up --database-url "$DATABASE_URL" --line pro

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

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-get --version 4 --line pro --up > river-pro-v4.up.sql
riverpro migrate-get --version 4 --line pro --down > river-pro-v4.down.sql

Added

  • Added DurablePeriodicJobsConfig.StartStaggerSpread and DurablePeriodicJobsConfig.StartStaggerThreshold which configure a "start stagger" for durable periodic jobs. If on start up a large backlog of periodic jobs are found to be scheduled before or at the current time, job start times are distributed randomly into the near future so they don't try to all run at once.
  • Added DurablePeriodicJobsConfig.NextRunAtRatchetFunc that configures a "ratchet" for next run times of durable jobs pulled from the database by modifying them before they're enqueued and get a new next run time. This protects against next run times in the past combined with periodic jobs that run frequently, which may cause many jobs to be enqueued all at once when a client restarts that's been offline for an extended period.
  • Added "ephemeral jobs" feature, allowing certain high frequency jobs to transition from running to deleted immediately so the space they occupy can be reclaimed immediately.
  • Imported Pro-specific River UI SQL queries to pave the way for a deeper Pro integration in River UI, including more Pro-specific functionality.
  • Added dead letter queue feature, which optionally transitions discarded jobs to a new river_job_dead_letter table instead of deleting them after DiscardedJobRetentionPeriod has elapsed.
  • Added Client.JobDeadLetterRetry* functions for resetting and retrying jobs that have failed all the way through to discarded and placed in the dead letter queue.
  • Added Client.JobDeadLetterGet* functions for retrieving dead letter jobs by ID.
  • Added per-queue job retention settings, configurable via riverpro.Config.ProQueues.CancelledJobRetentionPeriod/CompletedJobRetentionPeriod/DiscardedJobRetentionPeriod. Pro queues without custom retention settings inherit default retention from the main client.
  • Per-queue job cleaner prefers a batch size of 10,000, but will fall back to smaller batches of 1,000 on consecutive database timeouts.
  • Sequence and workflow supervisors also prefer a batch size of 10,000, but will fall back to smaller batches of 1,000 on consecutive database timeouts.

Changed

  • Remove unecessary transactions where a single database operation will do. This reduces the number of subtransactions created which can be an operational benefit it many cases.
  • Sequences optimized to remove redundant inbox records when promoting, resulting in more efficient promotion and reduced latency.
  • JobRetry now correctly places sequence jobs into pending to prevent them from immediately running, even if another job in the sequence is currently running. Fixes riverqueue/river#971.

Fixed

  • Insert-only clients weren't properly resolving queue configurations for partitioning, resulting in jobs being sent to the global partition instead of individual partitions. The underlying bugs were corrected and thorough test coverage was added to ensure this behaves correctly going forward.

Fixed

  • Fix use of custom schema in Client.WorkflowCancel* functions.

0.15.3 - 2025-06-06

v0.15.2 didn't correctly update internal version references due to a mistake in the release process. There are no additional changes in this release.

0.15.2 - 2025-06-06

Changed

  • The pro version 3 migration was updated to use IF NOT EXISTS for its table, index, and generated column additions, making it easier to add these async or concurrently as a manual step prior to the migration being run.

    Customers with large job tables should be aware that this migration may take some time due to the new generated partition key column on river_job.

0.15.1 - 2025-06-05

⚠️ v0.15.1 contains a minor amendment to the durable periodic jobs API to bring it more inline with other project conventions (see below). This is technically a breaking change and we wouldn't ship this, but we're making the change because it's less than 24 hours since the original change.

Changed

  • riverpro.Config.DurablePeriodicJob becomes riverpro.Config.DurablePeriodicJobs (plural) to match Config.PeriodicJobs in the non-pro client.

0.15.0 - 2025-06-04

⚠️ Internal APIs used for communication between River and River Pro have changed. Make sure to update River and River Pro to latest at the same time to get compatible versions. River Pro v0.15.0 is compatible with River v0.23.1.

⚠️ Version 0.15.0 contains a new database migration for the pro line, version 3. This migration adds new indexes to optimize sequence queries, as well as new indexes optimize concurrency limited queries, and a new table for durable periodic jobs. If migrating with the CLI, make sure to update it to its latest version:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-up --database-url "$DATABASE_URL" --line pro

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

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-get --version 3 --line pro --up > river-pro-v3.up.sql
riverpro migrate-get --version 3 --line pro --down > river-pro-v3.down.sql

Added

  • Added a Pro driver for use with database/sql: riverqueue.com/riverpro/driver/riverdatabasesql. Supports database/sql through Pgx or lib/pq. Often useful for compatibility with packages like Bun and GORM.
  • Added "durable" (i.e. database backed) periodic jobs.

Changed

  • Update river dependency to v0.23.1.
  • Precompute partition keys at job insertion time and optimize performance of concurrency limiting queries. This involves new indexes in pro migration v3. Compared to the prior release, benchmarks show a 70% decrease in job fetch time for concurrency limited queries in both partitioned and unpartitioned modes when testing with 100k available jobs and 1000 job batches. Frequent job fetches in high throughput queues will also trigger a cache on partition keys to further accelerate fetches by 85% over previous benchmarks.

Fixed

  • Fixed an issue with the sequence supervisor not waiting for all goroutines to shut down before exiting.
  • Optimized sequence promotion queries to resolve potential performance problems that surfaced for some users and to dramatically improve overall performance. The performance problems were caused by inefficient query plans that the Postgres query planner sometimes (but not always) chose to use instead of the more efficient plans. The combination of new indexes and query optimizations result in performance several times faster in the best case, and hundreds of times faster than degenerate scenarios.
  • Added clean errors when invalid nil args are given to NewClient.

0.14.0 - 2025-05-13

⚠️ Internal APIs used for communication between River and River Pro have changed. Make sure to update River and River Pro to latest at the same time to get compatible versions. River Pro v0.14.0 is compatible with River v0.22.0.

Changed

  • Pro pilot: When inserting jobs, don't call the SequencePromote query if there were no sequence jobs inserted.

0.13.0 - 2025-05-02

⚠️ Internal APIs used for communication between River and River Pro have changed. Make sure to update River and River Pro to latest at the same time to get compatible versions. River Pro v0.13.0 is compatible with River v0.21.0.

There are no significant changes to River Pro with this release, but it's been updated to point to River v0.21.0 so that there's a version of River Pro that's compatible with changes to River's driver interface that went out in v0.21.0.

0.12.0 - 2025-04-08

⚠️ Version 0.12.0 contains a new database migration for the pro line, version 2. This is a purely additive migration which adds a new river_producer table to facilitate global concurrency limits and other upcoming features, but it is required when using the Pro client. See documentation on running River Pro migrations. If migrating with the CLI, make sure to update it to its latest version:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-up --database-url "$DATABASE_URL" --line pro

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

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-get --version 2 --line pro --up > river-pro-v2.up.sql
riverpro migrate-get --version 2 --line pro --down > river-pro-v2.down.sql

In this release, River Pro gains a major new feature: concurrency limits! 🚀 Since the earliest River releases, users have been asking for a way to enforce granular controls on job concurrency, such as ensuring that only one instance of a given job kind can run globally at once, or ensuring that only N jobs per customer can run at once. This is now part of River Pro.

In addition to concurency limits, a new encryption feature has been added for users needing additional at-rest encryption of job arguments. 🔒

Added

  • New feature: concurrency limits. 🚦 Added the ability to enforce either a global or local (per-client) limit on how many jobs can run at once. By default these limits apply to the entire queue, but users can utilize the partition settings to apply the limits per job kind, or based on a subset of job arguments such as customer_id / tenant_id.

    Concurrency limits can be enabled by configuring your queue with riverpro.Config.ProQueues field (rather than in the river.Config.Queues field). The GlobalLimit field offers the ability to limit concurrency across all clients, while the LocalLimit option limits concurrency within a single client; both can be used together.

    The pro migration version 2 must be run prior to deploying this new code version.

  • A new riverencrypt package has been added along with riverencrypt/riversecretbox. The former provides function hooks for encrypting and decrypting jobs, and the latter an encryptor implementation using NaCl Secretbox, widely respected cryptography. The two are used together to encrypt all or some jobs in the database where extra sensitivity is required.

var key [32]byte
rand.Reader.Read(key[:])


riverClient, err := riverpro.NewClient(riverpropgxv5.New(dbPool), &riverpro.Config{
    Config: river.Config{
        Hooks: []rivertype.Hook{
            riverencrypt.NewEncryptHook(riversecretbox.NewEncryptor(key)),
        },
    },
})

Changed

  • The license received some minor updates to fix typos, improve formatting, and clarify some terms including the developer limit and termination clauses.

0.11.0 - 2025-03-14

⚠️ Version 0.11.0 moves to a unified pro migration line instead of separate sequence and workflow lines. While we initially envisioned having separate lines for the different Pro features, it has become clear that (a) some schema changes are needed for multiple Pro features, (b) most/all feature-specific schema changes can be made with little or no negative impact on users that don't use those features, and (c) the benefits of separating the migrations did not outweigh the added complexity.

To facilicate a clean migration, the pro migration line is idempotent and can be re-run safely from any unmigrated or partially migrated state. Running the first pro mgiration will also remove the deprecated sequence and workflow migration records from the river_migration table (if you're using River's internal migration system).

See documentation on running River Pro migrations. If migrating with the CLI, make sure to update it to the latest version:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-up --database-url "$DATABASE_URL" --line pro

Changed

  • The separate sequence and workflow migration lines have been consolidated into a single pro line. Users should move any migration tooling to use the pro line instead of the deprecated sequence and workflow lines.

Deprecated

  • The sequence and workflow migration lines are deprecated and will be removed in a future release. Users should migrate to the pro line instead.

0.10.0 - 2025-03-04

⚠️ Version 0.10.0 contains a new database migration for the sequence line, version 2. See documentation on running River Pro migrations. If migrating with the CLI, make sure to update it to its latest version:

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-up --database-url "$DATABASE_URL" --line sequence

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

Terminal window
go install riverqueue.com/riverpro/cmd/riverpro@latest
riverpro migrate-get --version 2 --line sequence --up > river-sequence-v2.up.sql
riverpro migrate-get --version 2 --line sequence --down > river-sequence-v2.down.sql

Changed

  • The sequence v2 migration adds a new partial index for pending sequence jobs to significantly improve the performance of the sequence supervisor's full scan.
  • The sequence supervisor now performs a full scan of all pending sequences when a node is elected as leader. This ensures that any sequences which may have been stalled due to a database crash are promoted. The full scan is skipped if the sequence scan index (from the v2 migration) does not exist for safety to avoid a performance hit on large production tables.
  • Update (non-Pro) River dependency to 0.18.0.

Fixed

  • Fixed a bug where all job inserts required the sequence migrations, even if not using the sequence feature.

0.9.0 - 2025-02-15

Changed

  • Remove range variable capture in for loops and use simplified range syntax. Each of these requires Go 1.22 or later, which was already our minimum required version since Go 1.23 was released.
  • Update (non-Pro) River dependency to 0.17.0.

v0.8.1 - 2025-01-30

Fixed

  • Bugs in the sequences implementation resulted in sequences sometimes being promoted prematurely, such as when another job in the sequence was already running. The queries have been corrected along with significantly improved test coverage to ensure correctness and prevent similar regressions.

v0.8.0 - 2025-01-28

Changed

  • Update (non-Pro) River dependency to 0.15.0.
  • Update (non-Pro) River dependency to 0.16.0.

v0.7.0 - 2024-12-16

Changed

  • Updated internal dependency of riverqueue/river to compensate for a change to baseservice.Archetype and a utility function.

Removed

  • Previously deprecated workflow APIs have been removed. Users should upgrade to v0.6.0 and fix any deprecations before upgrading to this release.

v0.6.0 - 2024-11-03

Added

  • Added riverworkflow.NameFromJobRow and riverworkflow.TaskFromJobRow to make it easy to extract the workflow name and workflow task name from a job's metadata.

Deprecated

In the v0.5.0 release, several top-level functions were added to the riverpro package by mistake. These have been deprecated in favor of the riverworkflow variants:

  • river.WorkflowIDFromJobRow becomes riverworkflow.IDFromJobRow.
  • river.JobListParams can be changed to the preexisting riverworkflow.JobListParams.
  • river.JobListParamsByID can be changed to the preexisting riverworkflow.JobListParamsByID.

In addition, more deprecations were marked in the riverworkflow package for things that should now be done with the main riverpro package. The next release will remove the remaining deprecations.

v0.5.1 - 2024-10-18

Fixed

  • Fixed an initialization panic when using the riverpropgxv5 driver with a regular river.Client.

v0.5.0 - 2024-10-08

⚠️ v0.5.0 makes significant changes to the way workflows are interacted with, and introduces a riverpro.Client to allow for better extensibility. Pro customers should migrate to this new interface for existing workflow usage, as well as to access new Pro features including Sequences and other upcoming functionality.

The API changes can be fixed with a few quick find & replaces and should take no more than a few minutes to complete:

  • Change river.NewClient to riverpro.NewClient.
  • Change river.Client to riverpro.Client.
  • Change river.ClientFromContext to riverpro.ClientFromContext.
  • Change river.Config to be nested as the Config attr within a riverpro.Config.
  • Change riverworkflow.Workflow to riverpro.NewWorkflow.
  • Change riverworkflow.Opts to riverpro.WorkflowOpts.
  • Change riverworkflow.TaskOpts to riverpro.WorkflowTaskOpts.
  • Change riverworkflow.Prepare(ctx, riverClient, to riverClient.WorkflowPrepare(ctx,.
  • Change riverworkflow.PrepareTx(ctx, riverClient, to riverClient.WorkflowPrepareTx(ctx,.

These APIs should be stable going forward as the new design is flexible enough to support all the upcoming functionality on the short term roadmap.

Added

  • Added a new riverpro.Client type and riverpro.NewClient constructor. This new Client should be used in River Pro projects in order to access Pro functionality like workflows, sequences, and other upcoming features. Most usage of the old riverworkflow package has been deprecated and will be removed in an upcoming release.
  • Introduce a new "Sequences" Pro feature ✨. Sequences enable a sequence of jobs to run in a strict one-at-a-time sequential order based on their insertion order. Sequences can be partitioned in several ways, including by arguments (full or partial), queue name, and job kind. Within each sequence, River Pro ensures that each sequence
  • Added WorkflowCancel and WorkflowCancelTx methods to riverpro.Client to enable cancelling all non-finalized tasks in a workflow.
  • Add riverpro.ClientFromContext to extract a riverpro.Client from workers, equivalent to river.ClientFromContext for regular clients.
  • Add riverpro.ContextWithClient to inject a client into the context in order to facilitate testing a worker that makes use of riverpro.ClientFromContext.

Breaking

  • The config argument has been removed from the riverpropgxv5.New constructor because it is now provided to the riverpro.Client constructor and propagated internally as necessary.
  • The deprecated Prepare method on riverworkflow.Workflow has been removed. Use the top-level riverpro.Client type along with its WorkflowPrepare / WorkflowPrepareTx methods.

Deprecated

  • ⚠️ Most of the riverworkflow package has been deprecated and will be removed in a future release. Users should transition to the riverpro.Client type along with its related workflow functionality. While this API shift is regrettable, it's necessary to ensure a good experience going forward and to be compatible with upcoming functionality.

v0.4.1 - 2024-09-23

Correctly upgrade River dependencies to v0.12.0.

v0.4.0 - 2024-09-23

  • Upgrade to use River v0.12.0.

v0.3.1 - 2024-09-17

Fixed

  • riverpropgxv5: UnwrapExecutor (for unwrapping a non-pro executor) now works when using a nil driver, which is required for use in functions like rivertest.RequireInsertedTx.

v0.3.0 - 2024-09-11

Fixed

  • Workflows: Fix an issue with directly mutating user-provided opts structs by ensuring we take copies of them prior to mutating. Without this fix, users who provided the same InsertOpts pointer to multiple workflow tasks would see identical metadata on all resulting tasks (rather than task-specific metadata as expected).

v0.2.1 - 2024-08-12

Fixed

  • Lowered the go directives in go.mod to Go 1.21, which River aims to support. A more modern version of Go is specified with the toolchain directive. This should provide more flexibility on the minimum required Go version for programs importing River.
  • Fixed a potential panic when unwrapping the pro driver and executor.

v0.2.0 - 2024-08-03

Added

  • Tasks can now be dynamically added to an existing workflow. The riverworkflow.FromExisting() constructor initiates a workflow from an existing job in that workflow. New tasks can be added using the same .Add() method that's used for a brand new worfklow. When preparing the workflow for insert using top-level Prepare and PrepareTx functions, existing jobs will be automatically loaded as needed to validate the workflow dependency graph.

  • New top-level functions in the riverworkflow package for Prepare and PrepareTx. These are used to prepare a workflow's tasks/jobs for insertion into the database, including validations of task dependencies. These functions should be preferred over workflow.Prepare which will be removed in the next release.

Deprecated

  • The Prepare method on riverworkflow.Workflow has been deprecated in favor of the new top-level Prepare and PrepareTx functions in that package. The new functions present a single interface for preparing workflow tasks for insertion, whether the workflow is brand new or for adding tasks to an existing workflow. This method will be removed in an upcoming release.

v0.1.1 - 2024-07-25

Added

  • This is the initial release of River Pro.