feat(schema): add WorkerDeployment.externalId and task_runs_v2.external_deployment_id - #4661
feat(schema): add WorkerDeployment.externalId and task_runs_v2.external_deployment_id#46610ski wants to merge 1 commit into
Conversation
|
WalkthroughThe changes add Merge Risk: 🟡 Moderate · up to The new PostgreSQL index migration can fail when deployed through the default transactional path because concurrent index creation requires a non-transactional execution path. Merge readiness depends on adjusting the migration or deployment procedure. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…al_deployment_id Migrations only, no code reads them yet. Postgres: nullable non-unique externalId on WorkerDeployment plus a CONCURRENTLY-built (environmentId, externalId) index in its own migration file. ClickHouse: external_deployment_id String DEFAULT '' on task_runs_v2 (plain String, not LowCardinality - commit SHAs are high-cardinality). Part of task run version skew protection (TRI-12998).
7625d61 to
603acad
Compare
@trigger.dev/build
trigger.dev
@trigger.dev/core
@trigger.dev/python
@trigger.dev/react-hooks
@trigger.dev/redis-worker
@trigger.dev/rsc
@trigger.dev/schema-to-json
@trigger.dev/sdk
commit: |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9f86bf16-4933-4e54-ad10-7f694b0ae9be
📒 Files selected for processing (4)
internal-packages/clickhouse/schema/040_add_task_runs_v2_external_deployment_id.sqlinternal-packages/database/prisma/migrations/20260818120000_add_worker_deployment_external_id/migration.sqlinternal-packages/database/prisma/migrations/20260818120100_add_worker_deployment_environment_id_external_id_index/migration.sqlinternal-packages/database/prisma/schema.prisma
🚧 Files skipped from review as they are similar to previous changes (1)
- internal-packages/database/prisma/schema.prisma
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review.
📜 Review details
⏰ Context from checks skipped due to timeout. (21)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (9, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (11, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (3, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (6, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (10, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (12, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (4, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (8, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (2, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (1, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (7, 12)
- GitHub Check: webapp / 🧪 Unit Tests: Webapp (5, 12)
- GitHub Check: runops-guard / runops-guard
- GitHub Check: internal / 🧪 Unit Tests: Internal
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e-webapp / 🧪 E2E Tests: Webapp
- GitHub Check: fk-cascade-guard / fk-cascade-guard
- GitHub Check: code-quality / code-quality
- GitHub Check: audit
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Build and publish previews
🧰 Additional context used
📓 Path-based instructions (2)
internal-packages/database/prisma/migrations/**/migration.sql
📄 CodeRabbit inference engine (internal-packages/database/CLAUDE.md)
internal-packages/database/prisma/migrations/**/migration.sql: When adding indexes to existing tables, useCREATE INDEX CONCURRENTLY IF NOT EXISTSto avoid production table locks.
Keep eachCONCURRENTLYindex in its own separate migration file, and add only one index per migration file.
Indexes on newly created tables may be created withoutCONCURRENTLYin the same migration asCREATE TABLE.
When adding an index for a new column on an existing table, use two migrations: firstALTER TABLE ... ADD COLUMN IF NOT EXISTS ..., then a separate migration containingCREATE INDEX CONCURRENTLY IF NOT EXISTS ....
Files:
internal-packages/database/prisma/migrations/20260818120000_add_worker_deployment_external_id/migration.sqlinternal-packages/database/prisma/migrations/20260818120100_add_worker_deployment_environment_id_external_id_index/migration.sql
internal-packages/clickhouse/schema/[0-9][0-9][0-9]_*.sql
📄 CodeRabbit inference engine (internal-packages/clickhouse/CLAUDE.md)
internal-packages/clickhouse/schema/[0-9][0-9][0-9]_*.sql: Migration file numbering: name files as0(N+1)_descriptive_name.sqlwhere N is the largest existing migration number inschema/; rebase and renumber if main adds migrations before opening a PR
DDL in migrations must be idempotent: useALTER TABLE ... ADD COLUMN IF NOT EXISTS,CREATE TABLE IF NOT EXISTS,DROP TABLE IF EXISTS,ADD INDEX IF NOT EXISTS,DROP INDEX IF EXISTS, andCREATE MATERIALIZED VIEW IF NOT EXISTSforms to allow out-of-order and retry-safe application
Files:
internal-packages/clickhouse/schema/040_add_task_runs_v2_external_deployment_id.sql
🧠 Learnings (2)
📚 Learning: 2026-02-03T18:48:31.790Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 2994
File: internal-packages/database/prisma/migrations/20260129162810_add_integration_deployment/migration.sql:14-18
Timestamp: 2026-02-03T18:48:31.790Z
Learning: For Prisma migrations targeting PostgreSQL: - When adding indexes to existing tables, create the index in a separate migration file and include CONCURRENTLY to avoid locking the table. - For indexes on newly created tables (in CREATE TABLE statements), you can create the index in the same migration file without CONCURRENTLY. This reduces rollout complexity for new objects while protecting uptime for existing structures.
Applied to files:
internal-packages/database/prisma/migrations/20260818120000_add_worker_deployment_external_id/migration.sqlinternal-packages/database/prisma/migrations/20260818120100_add_worker_deployment_environment_id_external_id_index/migration.sql
📚 Learning: 2026-03-22T13:49:20.068Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3244
File: internal-packages/database/prisma/migrations/20260318114244_add_prompt_friendly_id/migration.sql:5-5
Timestamp: 2026-03-22T13:49:20.068Z
Learning: For Prisma migration SQL files under `internal-packages/database/prisma/migrations/`, it is acceptable to create indexes with `CREATE INDEX` / `CREATE UNIQUE INDEX` (i.e., without `CONCURRENTLY`) when the parent table is introduced in the same PR and has no existing production rows yet. Only require `CREATE INDEX CONCURRENTLY` (or otherwise account for existing production data/locks) when the table already exists in production with data.
Applied to files:
internal-packages/database/prisma/migrations/20260818120000_add_worker_deployment_external_id/migration.sqlinternal-packages/database/prisma/migrations/20260818120100_add_worker_deployment_environment_id_external_id_index/migration.sql
🔇 Additional comments (2)
internal-packages/clickhouse/schema/040_add_task_runs_v2_external_deployment_id.sql (1)
1-7: LGTM!internal-packages/database/prisma/migrations/20260818120000_add_worker_deployment_external_id/migration.sql (1)
1-1: LGTM!
| @@ -0,0 +1 @@ | |||
| CREATE INDEX CONCURRENTLY IF NOT EXISTS "WorkerDeployment_environmentId_externalId_idx" ON "public"."WorkerDeployment"("environmentId", "externalId"); | |||
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Prisma versions and migration configuration:"
for pattern in package.json prisma.config.ts pnpm-lock.yaml yarn.lock package-lock.json; do
fd -t f -a -g "$pattern" . -x \
rg -n -C 2 '`@prisma/`|prisma migrate deploy|migration' {}
done
echo "Migration deployment wrappers:"
rg -n -C 5 \
--glob '*.yml' \
--glob '*.yaml' \
--glob '*.json' \
--glob '*.js' \
--glob '*.ts' \
'prisma migrate deploy|migrate deploy|BEGIN|COMMIT|transaction' .Repository: triggerdotdev/trigger.dev
Length of output: 1443
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Relevant package manifests and Prisma configuration:"
fd -t f \( -g 'package.json' -o -g 'prisma.config.*' -o -g 'schema.prisma' \) . \
-x sh -c 'echo "--- {}"; rg -n -C 4 "prisma|migrate|transaction|adapter" "{}" || true'
echo "Migration deployment references:"
rg -n -C 8 \
--glob '*.yml' --glob '*.yaml' --glob '*.json' --glob '*.js' --glob '*.cjs' \
--glob '*.mjs' --glob '*.ts' --glob '*.mts' --glob '*.sh' \
'prisma migrate deploy|db:migrate:deploy|migrate deploy|PRISMA_MIGRATE|migration' .
echo "Migration directory structure and neighboring migration files:"
fd -t f 'migration.sql' internal-packages/database/prisma/migrations \
| tail -n 12 \
| while read -r f; do echo "--- $f"; sed -n '1,8p' "$f"; doneRepository: triggerdotdev/trigger.dev
Length of output: 329
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "Relevant package manifests and Prisma configuration:"
git ls-files | rg '(^|/)(package\.json|prisma\.config\.[^/]+|schema\.prisma)$' |
while IFS= read -r f; do
echo "--- $f"
rg -n -C 4 'prisma|migrate|transaction|adapter' "$f" || true
done
echo "Migration deployment references:"
rg -n -C 8 \
--glob '*.yml' --glob '*.yaml' --glob '*.json' --glob '*.js' --glob '*.cjs' \
--glob '*.mjs' --glob '*.ts' --glob '*.mts' --glob '*.sh' \
'prisma migrate deploy|db:migrate:deploy|migrate deploy|PRISMA_MIGRATE|migration' .
echo "Migration directory structure and neighboring migration files:"
git ls-files 'internal-packages/database/prisma/migrations/*/migration.sql' |
tail -n 12 |
while IFS= read -r f; do
echo "--- $f"
sed -n '1,8p' "$f"
doneRepository: triggerdotdev/trigger.dev
Length of output: 50382
🌐 Web query:
Prisma 6.14 migrate deploy CREATE INDEX CONCURRENTLY transaction PostgreSQL migration outside transaction
💡 Result:
In Prisma, PostgreSQL migrations are not inherently wrapped in a transaction by default [1][2][3]. However, there is nuance regarding how Prisma executes statements: it may sometimes execute multiple statements within a single block or connection state, which can lead to complications with operations that strictly forbid being inside a transaction block [4][2]. For PostgreSQL operations like CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block, you must ensure the migration is executed outside of any transaction [5][4][2]. To achieve this in Prisma: 1. Manual Control: You can ensure a migration runs outside of a transaction by simply not wrapping your SQL in BEGIN and COMMIT statements [1][2]. If you are experiencing unexpected transaction behavior (such as when Prisma groups multiple statements), ensure your migration script specifically contains only the operation that requires being outside a transaction, or structure your SQL to explicitly avoid transaction blocks [4]. 2. Avoid Default Wrapping: Prisma does not add BEGIN/COMMIT to PostgreSQL migrations by default [1][3]. If you find your migration is being wrapped, inspect the generated migration.sql file to ensure no manual BEGIN/COMMIT statements were added, and verify that you are not running other commands in the same file that might trigger implicit transaction grouping [4]. 3. Migration Safety: When using operations like CREATE INDEX CONCURRENTLY, it is highly recommended to use tools like pgfence [5][6]. These tools analyze your migration files and help identify operations that require special handling, such as concurrent index creation, which can otherwise cause failures if executed within a transaction [5][6]. Note: While recent updates have focused on improving support for operations like CREATE INDEX CONCURRENTLY [7], the fundamental PostgreSQL requirement that these commands cannot run inside a transaction remains [5]. Always test your migrations in a staging environment to ensure the execution semantics match your expectations [6].
Citations:
- 1: Add an option to add transaction (
BEGINandCOMMIT) around migrations when generating them for PostgreSQL prisma/prisma#8080 - 2: Is a migration script wrapped inside a transaction? prisma/prisma#3774
- 3: https://github.com/prisma/prisma-engines/blob/6be410e/migration-engine/ARCHITECTURE.md
- 4: Confusing transaction semantics in Postgres migrations prisma/prisma#22922
- 5: https://www.prisma.io/docs/guides/integrations/pgfence
- 6: https://www.prisma.io/docs/orm/prisma-client/deployment/deploy-database-changes-with-prisma-migrate
- 7: feat: support CREATE INDEX CONCURRENTLY in migrations prisma/prisma-engines#5767
🌐 Web query:
site:prisma.io/docs Prisma Migrate CREATE INDEX CONCURRENTLY transaction PostgreSQL
💡 Result:
Prisma Migrate does not automatically generate or support CREATE INDEX CONCURRENTLY statements in its standard schema-based migration workflow [1]. Because PostgreSQL requires that CREATE INDEX CONCURRENTLY cannot run inside a transaction block, you must manually customize your migrations to use this feature [1]. To implement this safely with Prisma Migrate, follow these steps: 1. Create a migration file without applying it: Use the --create-only flag when generating your migration [2][3]. 2. Modify the generated SQL: Open the resulting migration.sql file and replace the standard CREATE INDEX statement with CREATE INDEX CONCURRENTLY [1]. 3. Run outside a transaction: Since CREATE INDEX CONCURRENTLY cannot execute inside a transaction, you must ensure the migration is executed outside of the transaction block that Prisma typically wraps around migrations [1]. You may need to manually run the SQL statement against your database using a tool like psql or an administrative interface, as Prisma Migrate's standard execution flow for PostgreSQL involves wrapping migrations in a single transaction [4][5]. Using tools like pgfence can help identify when you should consider using CONCURRENTLY for indexes to avoid performance degradation caused by table-locking during index builds [1][6]. Because standard Prisma migrations are transactional by default on PostgreSQL, manual intervention is necessary for any PostgreSQL command that forbids being run within a transaction [4][1][5].
Citations:
- 1: https://www.prisma.io/docs/guides/integrations/pgfence
- 2: https://www.prisma.io/docs/orm/prisma-migrate/workflows/unsupported-database-features
- 3: https://www.prisma.io/docs/orm/v6/prisma-migrate/workflows/unsupported-database-features
- 4: https://www.prisma.io/docs/orm/v8/migrations/applying-a-migration
- 5: https://www.prisma.io/docs/orm/next/migrations/applying-a-migration
- 6: https://www.prisma.io/docs/orm/prisma-client/deployment/deploy-database-changes-with-prisma-migrate
🌐 Web query:
site:github.com/prisma/prisma CREATE INDEX CONCURRENTLY migrate deploy transaction Prisma 6
💡 Result:
Prisma does not natively support CREATE INDEX CONCURRENTLY [1][2]. Attempting to use this command within a Prisma migration typically fails because PostgreSQL prohibits CREATE INDEX CONCURRENTLY from running inside a transaction block [1][3][4], and Prisma often executes migrations within a transaction or groups multiple statements in a way that creates an implicit transaction block [5][6]. Because Prisma Migrate does not have a built-in mechanism to handle this requirement, developers generally use the following workarounds: 1. Separate the index creation: Move the CREATE INDEX CONCURRENTLY statement into its own standalone migration file [7][2]. When a migration file contains only a single statement, Prisma may avoid wrapping it in an implicit transaction, allowing the concurrent operation to succeed [5][7]. 2. Manual execution: Perform the CREATE INDEX CONCURRENTLY operation manually on the production database, then manually update the _prisma_migrations table to mark the corresponding migration as applied [1][4][8]. This prevents Prisma from attempting to run the index creation again during subsequent deployments [4]. 3. Modify the SQL: Edit the generated migration file to ensure no other commands are grouped with the CREATE INDEX CONCURRENTLY statement [5][7]. Note that if you modify migration files, you must also update the migration checksum in the _prisma_migrations table, or Prisma will detect a mismatch and refuse to deploy [1][2][8]. These manual interventions are necessary because Prisma's automatic migration runner is designed for atomic, transactional application of schema changes, which inherently conflicts with the architectural requirements of PostgreSQL concurrent index builds [9][6].
Citations:
- 1: Support
CREATE INDEX CONCURRENTLY(PostgreSQL) prisma/prisma#14456 - 2: Support
CREATE INDEX CONCURRENTLY(PostgreSQL) prisma/prisma#14456 - 3: Add an option to add transaction (
BEGINandCOMMIT) around migrations when generating them for PostgreSQL prisma/prisma#8080 - 4: Run a migration by hand and update the migration table manually prisma/prisma#9154
- 5: Confusing transaction semantics in Postgres migrations prisma/prisma#22922
- 6: Is a migration script wrapped inside a transaction? prisma/prisma#3774
- 7: Disable transactions for a single migration prisma/prisma#10601
- 8: Deploying migrations and shadow db pre-check for creating them work differently prisma/prisma#29493
- 9: https://github.com/prisma/prisma/blob/main/skills/prisma-next-migrations/SKILL.md
🌐 Web query:
Prisma migrate deploy transaction source apply_migration raw_cmd PostgreSQL migration engine
💡 Result:
In the context of Prisma Migrate and PostgreSQL, the execution behavior is as follows: Prisma migrate deploy The prisma migrate deploy command is designed for production environments [1][2]. It applies all pending migrations found in your prisma/migrations directory that have not yet been recorded in the _prisma_migrations table [3]. It operates by serializing execution across concurrent processes using advisory locks (on PostgreSQL) to prevent multiple migration runs from interleaving [4][2]. Transaction Behavior On PostgreSQL, Prisma Migrate executes the entire migration run inside a single transaction [4]. If a migration fails, the entire transaction is rolled back, leaving the database in its original state before the run began [4]. While Prisma does not explicitly wrap every individual migration script in a BEGIN and COMMIT block by default [5][6], its engine design ensures that the deployment process remains atomic [4]. Historically, this was achieved via raw SQL execution paths (e.g., raw_cmd) [7][8], but the engine has evolved to use more controlled internal methods like apply_migration_script to better handle operations that cannot run inside transaction blocks, such as CREATE INDEX CONCURRENTLY [7]. Migration Engine Internals At the engine level (prisma-engines), the SqlSchemaConnector is responsible for applying migrations [9][10]. - raw_cmd: Historically used for executing raw SQL strings directly against the database [9][8]. - apply_migration / apply_migration_script: These are the higher-level internal methods used to apply migrations [9][8]. The migration engine uses these to handle the execution logic, which includes managing the migration state in the _prisma_migrations table [10][3] and ensuring that the schema is correctly updated [7]. In summary, when you run prisma migrate deploy on PostgreSQL, Prisma ensures atomicity for the deployment run by wrapping it in a transaction [4], while using internal engine methods to correctly handle specific SQL commands that have strict transactional requirements [7].
Citations:
- 1: https://www.prisma.io/docs/cli/migrate/deploy
- 2: https://www.prisma.io/docs/orm/prisma-migrate/workflows/development-and-production
- 3: https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/mental-model
- 4: https://www.prisma.io/docs/orm/v8/migrations/applying-a-migration
- 5: Add an option to add transaction (
BEGINandCOMMIT) around migrations when generating them for PostgreSQL prisma/prisma#8080 - 6: Is a migration script wrapped inside a transaction? prisma/prisma#3774
- 7: fix: support concurrent indexes in shadow db replay prisma/prisma-engines#5799
- 8: https://prisma.github.io/prisma-engines/doc/src/sql_schema_connector/lib.rs.html
- 9: https://prisma.github.io/prisma-engines/doc/sql_schema_connector/struct.SqlSchemaConnector.html
- 10: https://github.com/prisma/prisma-engines/blob/6be410e/migration-engine/ARCHITECTURE.md
🌐 Web query:
Prisma 6.14.0 migration-engine apply_migration PostgreSQL transaction source
💡 Result:
In Prisma, including version 6.14.0, the migration engine does not automatically wrap PostgreSQL migrations in a database transaction [1][2][3]. Key points regarding this behavior include: Default Non-Transactional Execution: By default, Prisma Migrate does not inject BEGIN or COMMIT statements into generated migration files [4][3]. This design choice is intended to ensure consistency across different database providers (some of which, like MySQL, do not support transactional DDL) and to provide flexibility [1][3]. Opt-in Transactional Behavior: If your migration requires atomicity, you can manually wrap the generated SQL in your migration file with BEGIN and COMMIT statements [5][6][3]. When you do this, Prisma will execute the contents of the file within that transaction block, provided the database engine supports it [2][5]. PostgreSQL Specifics: PostgreSQL supports transactional DDL. However, because Prisma does not explicitly control the transaction state for every migration, you are responsible for ensuring that the SQL commands you place inside a manual BEGIN/COMMIT block are compatible with being run in a transaction [7][2]. For example, some PostgreSQL commands, such as CREATE INDEX CONCURRENTLY, cannot run inside a transaction block and will fail if wrapped [7][4][2]. Internal Handling: The migration engine, specifically through the SqlSchemaConnector, handles the application of migration scripts [6][8][9]. While the engine itself maintains internal state (such as tracking progress in the _prisma_migrations table) to ensure it can resume failed migrations, it does not enforce a global transaction wrap for the migration files themselves [1][2]. If a manual transaction fails, the engine will report an error, and because the migration was wrapped in a transaction that was aborted, you may see errors related to the current transaction state being aborted, requiring you to resolve the migration manually [5][10].
Citations:
- 1: https://github.com/prisma/prisma-engines/blob/6be410e/migration-engine/ARCHITECTURE.md
- 2: Is a migration script wrapped inside a transaction? prisma/prisma#3774
- 3: https://www.prisma.io/blog/prisma-migrate-dx-primitives
- 4: Add an option to add transaction (
BEGINandCOMMIT) around migrations when generating them for PostgreSQL prisma/prisma#8080 - 5: Migration with transaction fails without good error message prisma/prisma#15295
- 6: https://mintlify.wiki/prisma/prisma-engines/components/schema-engine
- 7: Confusing transaction semantics in Postgres migrations prisma/prisma#22922
- 8: https://prisma.github.io/prisma-engines/doc/sql_schema_connector/struct.SqlSchemaConnector.html
- 9: https://prisma.github.io/prisma-engines/doc/src/sql_schema_connector/lib.rs.html
- 10: Adding an
enumfield on a model and removing anenumvalue at the same time generates a failing migration (Postgresql) prisma/prisma#24292
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT
curl -fsSL \
'https://api.github.com/repos/prisma/prisma-engines/git/trees/6.14.0?recursive=1' >"$tmp"
echo "Migration application source paths:"
jq -r '.tree[]?.path' "$tmp" |
rg 'migration-engine/.+(apply|migration|sql_schema_connector).+\.(rs|md)$' |
head -n 80
echo "Relevant source references:"
for path in \
migration-engine/connectors/sql-schema-connector/src/lib.rs \
migration-engine/connectors/sql-schema-connector/src/apply_migration.rs \
migration-engine/core/src/commands/apply_migrations.rs \
migration-engine/core/src/commands/apply_migration.rs
do
url="https://raw.githubusercontent.com/prisma/prisma-engines/6.14.0/$path"
if body="$(curl -fsSL "$url" 2>/dev/null)"; then
echo "--- $path"
printf '%s\n' "$body" |
rg -n -C 5 'apply_migration|raw_cmd|transaction|BEGIN|COMMIT|apply_migration_script' || true
fi
doneRepository: triggerdotdev/trigger.dev
Length of output: 199
🏁 Script executed:
#!/usr/bin/env bash
set -u
echo "Prisma engine tag lookup:"
curl -fsSL 'https://api.github.com/repos/prisma/prisma-engines/tags?per_page=100' |
jq -r '.[] | select(.name | test("6\\.14")) | [.name, .commit.sha] | `@tsv`' || true
echo "Prisma documentation wording:"
for url in \
'https://www.prisma.io/docs/guides/integrations/pgfence' \
'https://www.prisma.io/docs/orm/prisma-migrate/workflows/unsupported-database-features'
do
echo "--- $url"
curl -fsSL "$url" 2>/dev/null |
sed 's/<[^>]*>/ /g' |
tr -s '[:space:]' ' ' |
rg -o -i '.{0,180}(transaction|concurrent|migration).{0,260}' |
head -n 12 || true
doneRepository: triggerdotdev/trigger.dev
Length of output: 9969
🌐 Web query:
site:prisma.io/docs/guides/integrations/pgfence "outside a transaction block" "Prisma Migrate"
💡 Result:
Prisma Migrate typically runs migrations within a transaction block to ensure that if a migration fails, the changes are rolled back. However, certain SQL operations, such as CREATE INDEX CONCURRENTLY in PostgreSQL, are prohibited from running inside a transaction block [1]. When you need to perform such operations, you must manually edit the generated migration SQL file to include the required commands (e.g., adding CONCURRENTLY) and ensure the migration runs outside of a transaction [1]. Since Prisma Migrate applies migrations in a transaction by default, you may need to handle the execution of these specific, non-transactional SQL statements outside of the standard Prisma Migrate workflow if the tooling does not support disabling the transaction wrapper for individual migration files. For database safety when performing these operations, it is recommended to use tools like pgfence to analyze your migration files for dangerous patterns or unsupported operations before they are applied to your production database [1].
Citations:
🌐 Web query:
site:prisma.io/docs "Prisma Migrate runs migrations in a transaction" "CREATE INDEX CONCURRENTLY"
💡 Result:
Prisma Migrate does not natively support running CREATE INDEX CONCURRENTLY commands because this operation cannot be executed inside a standard transaction block [1], which is the default behavior for migrations in PostgreSQL [2][3]. When using PostgreSQL, Prisma Migrate wraps the execution of migration SQL files within a single transaction [2][3]. Because the PostgreSQL command CREATE INDEX CONCURRENTLY specifically requires that it not run inside a transaction block, attempting to include it in a standard Prisma migration will result in an error [1]. To use CREATE INDEX CONCURRENTLY with Prisma Migrate, you must manually modify the generated migration SQL file to remove the implicit transaction wrapping or ensure the statement is executed in a way that satisfies PostgreSQL requirements [1]. Specifically, if you modify a migration to include this command, you must be aware that the migration will no longer be atomic in the same way as standard migrations, as it must exist outside of the transaction block [1]. It is recommended to use database migration safety tools (such as pgfence) to analyze your migration files for heavy locking operations like standard index creation and to assist in generating the appropriate SQL for concurrent operations [1][4]. Note that Prisma's schema definition language does not currently provide a configuration option to automatically generate concurrent index migrations [5].
Citations:
- 1: https://www.prisma.io/docs/guides/integrations/pgfence
- 2: https://www.prisma.io/docs/orm/next/migrations/applying-a-migration
- 3: https://www.prisma.io/docs/orm/next/migrations/the-migration-graph
- 4: https://www.prisma.io/docs/orm/prisma-client/deployment/deploy-database-changes-with-prisma-migrate
- 5: https://www.prisma.io/docs/orm/reference/prisma-schema-reference
Run this migration outside a transaction.
prisma migrate deploy runs migrations in a transaction by default, but PostgreSQL rejects CREATE INDEX CONCURRENTLY inside a transaction. Use a non-transactional deployment path for this migration.
Source: MCP tools
2 participants
Migrations only, no code reads them yet. Postgres: nullable non-unique externalId on WorkerDeployment plus a CONCURRENTLY-built (environmentId, externalId) index in its own migration file. ClickHouse: external_deployment_id String DEFAULT '' on task_runs_v2 (plain String, not LowCardinality - commit SHAs are high-cardinality). Part of task run version skew protection (TRI-12998).