Queue policy migration depends on pg-boss v12 internals

[Erilla]

Question

createDiscoveryQueue runs exclusiveQueuePolicyMigration on every worker start (packages/database/src/queue.ts). It exists because pg-boss makes createQueue idempotent and refuses policy changes through updateQueue, so an already-deployed standard or stately queue would keep letting singleton-key enqueue retries duplicate. The migration therefore reaches past the pg-boss API and writes its tables directly:

• LOCK TABLE pgboss.queue and pgboss.job in SHARE ROW EXCLUSIVE MODE.
• Cancels all but the FIFO head per (name, singleton_key) by setting state = 'cancelled'.
• Rewrites policy on both pgboss.job and pgboss.queue.
• Selects runnable jobs as state < 'completed', which relies on the ordering of the pgboss.job_state enum.

Verified by an integration test that upgrades a deployed standard and stately queue without losing work, but the test pins the same version as the code. A pg-boss major upgrade can rename these tables, reorder the enum, or change the policy semantics, and the failure mode is silent: duplicate discovery jobs or cancelled live work rather than an error.

To decide: whether to accept this as a documented version pin (and where to record it so a dependency bump re-verifies it), or to remove it once every deployed environment is known to be on exclusive and the migration is dead code.

Introduced in #29.