chore(deps): update dependency pg-boss to v10 #44

MAJOR: Node 20 is now the minimum required version
MAJOR: PostgreSQL 13 is now the minimum required version. The dependency on the pgcrypto extension has been removed.
MAJOR: Automatic migration from v9 or lower is not currently available. A new partitioned job table was created, as well as new queue storage policies that make it difficult to honor the previous unique constraints in an upgrade scenario. The safest option is to manually move jobs from pgboss 9 to v10 via the API, or at least use the API to prepare for a manual migration via INSERT ... SELECT.
MAJOR: Job retries are now opt-out instead of opt-in. The default retryLimit is now 2 retries. This will cause an issue for any job handlers that aren't idempotent. Consider setting retryLimit=0 on these queues if needed.
MAJOR: Queues must now be created before API or direct SQL INSERT will work. See migration notes below. Each queue has a storage policy (see below) and represents a child table in a partitioning hierarchy. Additionally, queues store default retry and retention policies that will be auto-applied to all new jobs. See the docs for more on queue operation such as `createQueue().
- standard (default): Standard queues are the default queue policy, which supports all existing features. This will provision a dedicated job partition for all jobs with this name.
- short: Short queues only allow 1 item to be queued (in created state), which replaces the previous sendSingleton() and sendOnce() functions.
- singleton: Singleton queues only allow 1 item to be active, which replaces the previous fetch() option enforceSingletonQueueActiveLimit.
- stately: Stately queues are a combination of short and singleton, only allowing 1 job to be queued and 1 job active.
MAJOR: The handler function in work() was standardized to always receive an array of jobs. One simple way to migrate a single job handler (batchSize=1) is a destructuring assignment like the following.
```
// v9
await boss.work(queue, (job) => handler(job))
// v10
await boss.work(queue, ([ job ]) => handler(job))
```
MAJOR: teamSize, teamConcurrency, and teamRefill were removed from work() to simplify worker polling use cases. As noted above, enforceSingletonQueueActiveLimit was also removed.
MAJOR: Dead letter queues replace completion jobs. Failed jobs will be added to optional dead letter queues after exhausting all retries. This is preferred over completion jobs to gain retry support via work(). Additionally, dead letter queues only make a copy of the job if it fails, instead of filling up the job table with numerous, mostly unneeded completion jobs.
- onComplete option in send() and insert() has been removed
- onComplete(), offComplete(), and fetchCompleted() have been removed
- deadLetter option added to send() and insert() and createQueue()
MAJOR: Dropped the following API functions in favor of policy queues
- sendOnce()
- sendSingleton()
MAJOR: The following API functions now require name arguments
- complete(name, id, data)
- fail(name, id, data)
- cancel(name, id)
- getJobById(name, id)

MAJOR: The contract for getJobById() and the includeMetadata option for fetch() and work() were standardized to the following.

interface JobWithMetadata<T = object> {
  id: string;
  name: string;
  data: T;
  priority: number;
  state: 'created' | 'retry' | 'active' | 'completed' | 'cancelled' | 'failed';
  retryLimit: number;
  retryCount: number;
  retryDelay: number;
  retryBackoff: boolean;
  startAfter: Date;
  startedOn: Date;
  singletonKey: string | null;
  singletonOn: Date | null;
  expireIn: PostgresInterval;
  createdOn: Date;
  completedOn: Date | null;
  keepUntil: Date;
  deadLetter: string,
  policy: string,
  output: object
}

MAJOR: The columns in the job and archive table were renamed to standardize to snake case. A sample job table script showing these is below.

CREATE TABLE pgboss.job (
  id uuid not null default gen_random_uuid(),
  name text not null,
  priority integer not null default(0),
  data jsonb,
  state pgboss.job_state not null default('created'),
  retry_limit integer not null default(0),
  retry_count integer not null default(0),
  retry_delay integer not null default(0),
  retry_backoff boolean not null default false,
  start_after timestamp with time zone not null default now(),
  started_on timestamp with time zone,
  singleton_key text,
  singleton_on timestamp without time zone,
  expire_in interval not null default interval '15 minutes',
  created_on timestamp with time zone not null default now(),
  completed_on timestamp with time zone,
  keep_until timestamp with time zone NOT NULL default now() + interval '14 days',
  output jsonb,
  dead_letter text,
  policy text,
  CONSTRAINT job_pkey PRIMARY KEY (name, id)
) PARTITION BY LIST (name)

MAJOR: work() options newJobCheckInterval and newJobCheckIntervalSeconds have been replaced by pollingIntervalSeconds. The minimum value is 0.5, making 500ms the minimum allowed value.
MAJOR: stop() option destroy was renamed to close. Previously, destroy was defaulted to false, to leave the internal connection database open which was created by start(). Now, close will default to true.
MAJOR: noSupervisor and noScheduling were renamed to a more intuitive naming convention.
- If using noSupervisor: true to disable mainteance, instead use supervise: false
- If using noScheduling: true to disable scheduled cron jobs, use schedule: false
MINOR: Added new function deleteJob() to provide fetch -> delete semantics when job throttling and/or storage is not desired.

MINOR: send() and insert() cascade configuration from policy queues (if they exist) and then global settings in the constructor. Use the following table to help identify which settings are inherited and when.

Setting	API	Queue	Constructor
`retryLimit`	`send()`, `insert()`, `createQueue()`	✔️	✔️
`retryDelay`	`send()`, `insert()`, `createQueue()`	✔️	✔️
`retryBackoff`	`send()`, `insert()`, `createQueue()`	✔️	✔️
`expireInSeconds`	`send()`, `insert()`, `createQueue()`	✔️	✔️
`expireInMinutes`	`send()`, `createQueue()`	✔️	✔️
`expireInHours`	`send()`, `createQueue()`	✔️	✔️
`retentionSeconds`	`send()`, `createQueue()`	✔️	✔️
`retentionMinutes`	`send()`, `createQueue()`	✔️	✔️
`retentionHours`	`send()`, `createQueue()`	✔️	✔️
`retentionDays`	`send()`, `createQueue()`	✔️	✔️
`deadLetter`	`send()`, `insert()`, `createQueue()`	✔️

MINOR: Added primary key to job archive to support replication use cases such as read replicas or high availability standbys.
MINOR: Added a new constructor option, migrate:false, to block an instance from attempting to migrate to the latest database schema version. This is useful if the configured credentials don't have schema modification privileges or complete control of when and how migrations are run is required.
MINOR: The expired failed state has been consolidated into failed for simplicity.
MINOR: Added priority:false option to work() and fetch() to opt out of priority sorting during job fetching. If a queue is very large and not using the priority feature, this may help job fetch performance.
MINOR: Added a maintenance function, maintain(), if needed for serverless and/or externally scheduled maintenance use cases.
MINOR: Added functions isInstalled() and schemaVersion()
MINOR: stop() will now wait for the default graceful stop timeout (30s) before resolving its promise. The stopped event will still emit. If you want to the original behavior, set the new wait option to false.
MINOR: Added id property as an option to send() for pre-assigning the job id. Previously, only insert() supported pre-assignment.
MINOR: Removed internal usage of md5() hashing function for those needing FIPS compliance.

Migration Notes

This section will contain notes and tips on different migration strategies from v9 and below to v10. Since auto-migration is not supported, there are a few manual options to get all of your jobs into v10 from v9.

API option

For each queue, use createQueue(), fetch(), insert() to pull jobs from v9 and insert into v10.

SQL option

Something along the lines of INSERT INTO v10.job (...) SELECT ... FROM v9.job is possible in SQL, but the queues have to be created first.

Run SELECT pgboss.create_queue(name, options).
Insert records into pgboss.job.

Hybrid option

Create all required queues using the API
Now that queues are created, iterate through each source queue, and insert only queued items (state=created) in SQL.

const queues = await boss.getQueues();

for (const queue of queues) {
    try {
        const sql = `
            INSERT INTO ${targetSchema}.job (
                id,
                name,
                priority,
                data,
                retry_limit,
                retry_count,
                retry_delay,
                retry_backoff,
                start_after,
                singleton_key,
                singleton_on,
                expire_in,
                created_on,
                keep_until,
                output,
                policy
            )
            SELECT 
                id,
                name,
                priority,
                data,
                retryLimit,
                retryCount,
                retryDelay,
                retryBackoff,
                startAfter,
                singletonKey,
                singletonOn,
                expireIn,
                createdOn,
                keepUntil,
                output jsonb,
                '${queue.policy}' as policy
            FROM ${sourceSchema}.job
            WHERE name = '${queue.name}'
                AND state = 'created'
            ON CONFLICT DO NOTHING
        `;

        const { rowCount } = await client.query(sql);

        if (rowCount) {
            log.info(`pg-boss v10 migration: Migrated ${rowCount} jobs in queue ${queue.name}`);
        }
    } catch (error) {
        log.error(`pg-boss v10 migration: error copying jobs from '${queue.name}': ${error.message}`);
    }
}

What's Changed

Update readme.md by @LavredisG in https://github.com/timgit/pg-boss/pull/431
v10 by @timgit in https://github.com/timgit/pg-boss/pull/425

New Contributors

@LavredisG made their first contribution in https://github.com/timgit/pg-boss/pull/431

Full Changelog: timgit/pg-boss@9.0.3...10.0.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

renovate bot force-pushed the renovate/pg-boss-10.x branch 2 times, most recently from 1c61d52 to 0a565c7 Compare August 24, 2024 05:09

renovate bot force-pushed the renovate/pg-boss-10.x branch 5 times, most recently from 152def8 to 66adcd1 Compare August 28, 2024 21:26

renovate bot force-pushed the renovate/pg-boss-10.x branch from 66adcd1 to 863fea3 Compare September 11, 2024 13:03

chore(deps): update dependency pg-boss to v10

dae485d

renovate bot force-pushed the renovate/pg-boss-10.x branch from 863fea3 to dae485d Compare September 14, 2024 15:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update dependency pg-boss to v10 #44

chore(deps): update dependency pg-boss to v10 #44

renovate bot commented Aug 17, 2024 •

edited

Loading

chore(deps): update dependency pg-boss to v10 #44

Are you sure you want to change the base?

chore(deps): update dependency pg-boss to v10 #44

Conversation

renovate bot commented Aug 17, 2024 • edited Loading

Release Notes

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

What's Changed

New Contributors

Migration Notes

API option

SQL option

Hybrid option

What's Changed

New Contributors

Configuration

renovate bot commented Aug 17, 2024 •

edited

Loading