Eric Allam
5ba8557a51
## Summary v3 (the engine that ran the SDK v3 era, internally `RunEngineVersion.V1`) is end-of-life. Following the removal of the v3 execution apps ([#4194](https://github.com/triggerdotdev/trigger.dev/pull/4194)) and the legacy dev websocket ([#4198](https://github.com/triggerdotdev/trigger.dev/pull/4198)), this removes the remaining v3 execution stack from the server. Clients still on v3 (an old SDK or CLI that has not upgraded) keep getting a clear "upgrade to v4" response. Triggers, batch triggers, reschedules, and deploys that resolve to v3 are rejected with a graceful 4xx pointing at the migration guide, never a 5xx, so a stale client cannot affect server health. Self-hosted instances still running v3 should stay on the 4.5.x release line until they migrate. ## What is removed - The MarQS queue and its shared/dev queue consumers. - The v3 socket.io namespaces (coordinator, provider, shared-queue) and the v3 run lifecycle services (attempt, checkpoint, and batch-resume). - The graphile-worker background job system; all live jobs already run on `@trigger.dev/redis-worker`. - The `DEPRECATE_V3_ENABLED` flag: v3 is now rejected unconditionally, so the flag is gone. - Unused v3 exports from `@trigger.dev/core` (the `v3/zodNamespace` subpath and the legacy socket message catalogs) and the now-dead MarQS environment variables. ## What stays The v4 engine is untouched. The graceful v3 rejection boundary stays, `determineEngineVersion` still detects a v3 project so it can reject it, and the batch service plus batch-completion worker stay for current clients. Live queue concurrency limits and metrics now read from the v4 run engine instead of MarQS, and a brand-new dev environment now defaults to v4. ## Dependency cleanup Removes webapp dependencies left unused by this change: `seedrandom` and `semver` (only the removed v3 code used them) plus a set that was already dead, their orphaned `@types` packages, and two dead files. Adds a `knip:deps` script and a `knip.json` config so unused dependencies can be found the same way going forward.
2.1 KiB
2.1 KiB
Database Package
Prisma 6.14.0 client and schema for PostgreSQL (@trigger.dev/database).
Schema
Located at prisma/schema.prisma. Key models include TaskRun, BackgroundWorker, BackgroundWorkerTask, WorkerDeployment, RuntimeEnvironment, and Project.
Engine Versions
enum RunEngineVersion {
V1 // Retired v3 engine - no longer executes; kept for historical rows and rejection
V2 // Current (run-engine + redis-worker)
}
New code should always target V2.
Creating Migrations
- Edit
prisma/schema.prisma - Generate migration:
cd internal-packages/database pnpm run db:migrate:dev:create --name "descriptive_name" - Clean up generated migration - remove extraneous lines for:
_BackgroundWorkerToBackgroundWorkerFile_BackgroundWorkerToTaskQueue_TaskRunToTaskRunTag_WaitpointRunConnections_completedWaitpointsSecretStore_key_idx- Various
TaskRunindexes (unless you added them)
- Apply migration:
pnpm run db:migrate:deploy && pnpm run generate
Index Migration Rules
When adding indexes to existing tables:
- Use
CREATE INDEX CONCURRENTLY IF NOT EXISTSto avoid table locks in production - CONCURRENTLY indexes must be in their own separate migration file - they cannot be combined with other schema changes (PostgreSQL requirement)
- Only add one index per migration file
- Pre-apply the index manually in production before deploying the migration (Prisma will skip creation if the index already exists)
Indexes on newly created tables (in the same migration as CREATE TABLE) do not need CONCURRENTLY and can be in the same migration file.
When adding an index on a new column on an existing table, use two migrations:
- First migration:
ALTER TABLE ... ADD COLUMN IF NOT EXISTS ...(the column) - Second migration:
CREATE INDEX CONCURRENTLY IF NOT EXISTS ...(the index, in its own file)
See README.md in this directory and ai/references/migrations.md for the full index workflow.
Read Replicas
Use $replica from ~/db.server for read-heavy queries in the webapp.