Skip to main content

RFC — Migrate off gocraft/work (EOL) — evaluate asynq / river

Bucket item: A3 · Class: ⚪ Intangible (tracked tech-debt) · Jira Story: TF-3503 · Epic: TF-3500

Context / Problem​

The background-job framework github.com/gocraft/work v0.5.1 (go.mod:14) is effectively unmaintained — last release ~2019, no security fixes. It is a long-lived dependency in the job path.

This item is classed ⚪ Intangible: it is tracked tech-debt to de-risk, not scheduled delivery work this quarter. The migration is high-effort and should be scoped before any new job types are added on the old framework.

Proposed direction (not yet decided)​

Evaluate a maintained successor and produce a migration plan:

  • asynq — Redis-backed, actively maintained, closest programming model to gocraft/work.
  • river — Postgres-backed; attractive if we want to drop the Redis dependency and get transactional job enqueue.

Execution plan (call to action — this quarter: evaluation only)​

  1. Inventory current usage: enqueue sites, job types, middleware, retry/uniqueness semantics on gocraft/work.
  2. Spike asynq and river against 2–3 representative jobs; compare backpressure, observability, retry, and ops burden (Redis vs Postgres).
  3. Produce a decision RFC (AGREED) + a phased migration task-breakdown; do not migrate under this item — that becomes its own sized initiative if the effort warrants a standard folder.

Risks​

  • Risk of inaction: unmaintained framework, no security fixes; risk grows with each new job type.
  • Risk of migration: high-effort, touches the whole job path — hence evaluate-and-de-risk first, commit later.

Open questions​

  1. Redis-backed (asynq) vs Postgres-backed (river) — does dropping Redis matter for CDP ops?
  2. Is there an in-place-compatible shim, or is a rewrite of each job type required?
  3. If the evaluation shows the migration is multi-week, does it graduate to its own standard initiative (per the bucket's "big migration → standard initiative" guard)?