[GH-ISSUE #1880] Failing Migrations when upgrading from 1.11 to 1.12/1.12.1 (docker)

kerem commented

2026-02-26 18:47:32 +03:00

Owner

Originally created by @ArbiterGR on GitHub (Jul 4, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/1880

Issue Description

I'm getting the following error upon applying migration on the new version:

`A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 20250522054050_add_organisations

Database error code: 23502

Database error:
ERROR: null value in column "organisationId" of relation "OrganisationGroup" violates not-null constraint
DETAIL: Failing row contains (org_group_xirhimhddwenzbbf, null, INTERNAL_TEAM, MEMBER, null, 2, ADMIN).

DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E23502), message: "null value in column "organisationId" of relation "OrganisationGroup" violates not-null constraint", detail: Some("Failing row contains (org_group_xirhimhddwenzbbf, null, INTERNAL_TEAM, MEMBER, null, 2, ADMIN)."), hint: None, position: None, where_: None, schema: Some("public"), table: Some("OrganisationGroup"), column: Some("organisationId"), datatype: None, constraint: None, file: Some("execMain.c"), line: Some(1972), routine: Some("ExecConstraints") }`

By rolling back the failed migration using "npx prisma migrate resolve --rolled-back "20250522054050_add_organisations" --schema ../../packages/prisma/schema.prisma" i'm able to downgrade to version 1.11 which works.

Steps to Reproduce

No response

Expected Behavior

No response

Current Behavior

No response

Screenshots (optional)

No response

Operating System [e.g., Windows 10]

No response

Browser [e.g., Chrome, Firefox]

No response

Version [e.g., 2.0.1]

No response

Please check the boxes that apply to this issue report.

I have searched the existing issues to make sure this is not a duplicate.
I have provided steps to reproduce the issue.
I have included relevant environment information.
I have included any relevant screenshots.
I understand that this is a voluntary contribution and that there is no guarantee of resolution.
I want to work on creating a PR for this issue if approved

Originally created by @ArbiterGR on GitHub (Jul 4, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/1880 ### Issue Description I'm getting the following error upon applying migration on the new version: `A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve Migration name: 20250522054050_add_organisations Database error code: 23502 Database error: ERROR: null value in column "organisationId" of relation "OrganisationGroup" violates not-null constraint DETAIL: Failing row contains (org_group_xirhimhddwenzbbf, null, INTERNAL_TEAM, MEMBER, null, 2, ADMIN). DbError { severity: "ERROR", parsed_severity: Some(Error), code: SqlState(E23502), message: "null value in column \"organisationId\" of relation \"OrganisationGroup\" violates not-null constraint", detail: Some("Failing row contains (org_group_xirhimhddwenzbbf, null, INTERNAL_TEAM, MEMBER, null, 2, ADMIN)."), hint: None, position: None, where_: None, schema: Some("public"), table: Some("OrganisationGroup"), column: Some("organisationId"), datatype: None, constraint: None, file: Some("execMain.c"), line: Some(1972), routine: Some("ExecConstraints") }` By rolling back the failed migration using "npx prisma migrate resolve --rolled-back "20250522054050_add_organisations" --schema ../../packages/prisma/schema.prisma" i'm able to downgrade to version 1.11 which works. ### Steps to Reproduce _No response_ ### Expected Behavior _No response_ ### Current Behavior _No response_ ### Screenshots (optional) _No response_ ### Operating System [e.g., Windows 10] _No response_ ### Browser [e.g., Chrome, Firefox] _No response_ ### Version [e.g., 2.0.1] _No response_ ### Please check the boxes that apply to this issue report. - [ ] I have searched the existing issues to make sure this is not a duplicate. - [ ] I have provided steps to reproduce the issue. - [ ] I have included relevant environment information. - [ ] I have included any relevant screenshots. - [ ] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

status: triage

label

2026-02-26 18:47:32 +03:00

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@Sarmingsteiner commented on GitHub (Jul 4, 2025):

Same here :-(

@Sarmingsteiner commented on GitHub (Jul 4, 2025): Same here :-(

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 4, 2025):

same

@seamon67 commented on GitHub (Jul 4, 2025): same

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 4, 2025):

Reverting back to v1.11.1 fixes it but I did a DB backup restore anyway.

@seamon67 commented on GitHub (Jul 4, 2025): Reverting back to v1.11.1 fixes it but I did a DB backup restore anyway.

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@ad1217 commented on GitHub (Jul 4, 2025):

This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active Subscription and set customerId to a random uuid for each Team. This created an organization for those teams during the migration. For example (one team with id=1):

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL;
INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp);

@ad1217 commented on GitHub (Jul 4, 2025): This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active `Subscription` and set `customerId` to a random uuid for each `Team`. This created an organization for those teams during the migration. For example (one team with id=1): ```sql UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp); ```

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 4, 2025):

Should we wait for a proper fix?

@seamon67 commented on GitHub (Jul 4, 2025): Should we wait for a proper fix?

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@ArbiterGR commented on GitHub (Jul 5, 2025):

Should we wait for a proper fix?

Let's hope they see this soon.

@ArbiterGR commented on GitHub (Jul 5, 2025): > Should we wait for a proper fix? Let's hope they see this soon.

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@Sarmingsteiner commented on GitHub (Jul 5, 2025):

This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active Subscription and set customerId to a random uuid for each Team. This created an organization for those teams during the migration. For example (one team with id=1):

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL;
INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp);

Thanks for the suggested workaround! Unfortunately, it did not resolve the issue - the migration still fails.

@Sarmingsteiner commented on GitHub (Jul 5, 2025): > This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active `Subscription` and set `customerId` to a random uuid for each `Team`. This created an organization for those teams during the migration. For example (one team with id=1): > > UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; > INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp); Thanks for the suggested workaround! Unfortunately, it did not resolve the issue - the migration still fails.

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@MinecollYT commented on GitHub (Jul 5, 2025):

I though it was a issue on my side, which I tried to fix and well.. bricked my whole db

@MinecollYT commented on GitHub (Jul 5, 2025): I though it was a issue on my side, which I tried to fix and well.. bricked my whole db

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 5, 2025):

I though it was a issue on my side, which I tried to fix and well.. bricked my whole db

That's why you backup :D

@seamon67 commented on GitHub (Jul 5, 2025): > I though it was a issue on my side, which I tried to fix and well.. bricked my whole db That's why you backup :D

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@MinecollYT commented on GitHub (Jul 5, 2025):

I though it was a issue on my side, which I tried to fix and well.. bricked my whole db

That's why you backup :D

Your 100% right! I do create backups of documenso... at least I do now xD thank god it wasn't a productive system

@MinecollYT commented on GitHub (Jul 5, 2025): > > I though it was a issue on my side, which I tried to fix and well.. bricked my whole db > > That's why you backup :D Your 100% right! I do create backups of documenso... at least I do now xD thank god it wasn't a productive system

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 11, 2025):

Will this be fixed or nah?

@seamon67 commented on GitHub (Jul 11, 2025): Will this be fixed or nah?

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@x-stp commented on GitHub (Jul 12, 2025):

same 😭

@x-stp commented on GitHub (Jul 12, 2025): same 😭

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@abuintel commented on GitHub (Jul 13, 2025):

Hopefully this gets fixed soon

@abuintel commented on GitHub (Jul 13, 2025): Hopefully this gets fixed soon

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 18, 2025):

Alright, I couldn't wait any longer.

In v1.11.1, you have to do these in your postgres container

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL;
INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp);

Thanks to @ad1217

Then you can upgrade to v1.12.1
There seems to be a lot of changes.

@seamon67 commented on GitHub (Jul 18, 2025): Alright, I couldn't wait any longer. In v1.11.1, you have to do these in your postgres container UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp); Thanks to @ad1217 Then you can upgrade to v1.12.1 There seems to be a lot of changes.

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@ArbiterGR commented on GitHub (Jul 23, 2025):

Alright, I couldn't wait any longer.

In v1.11.1, you have to do these in your postgres container

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp);

Thanks to @ad1217

Then you can upgrade to v1.12.1 There seems to be a lot of changes.

Thanks for the fix. It sucks that the developers do not seem read the reported issues.

@ArbiterGR commented on GitHub (Jul 23, 2025): > Alright, I couldn't wait any longer. > > In v1.11.1, you have to do these in your postgres container > > UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp); > > Thanks to [@ad1217](https://github.com/ad1217) > > Then you can upgrade to v1.12.1 There seems to be a lot of changes. Thanks for the fix. It sucks that the developers do not seem read the reported issues.

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@x-stp commented on GitHub (Jul 23, 2025):

@ElTimuro thoughts? cc @ephraimduncan

@x-stp commented on GitHub (Jul 23, 2025): @ElTimuro thoughts? cc @ephraimduncan

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@pepicrft commented on GitHub (Jul 30, 2025):

This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active Subscription and set customerId to a random uuid for each Team. This created an organization for those teams during the migration. For example (one team with id=1):

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL;
INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp);

This solved my issue, but now I'm seeing the following:

@pepicrft commented on GitHub (Jul 30, 2025): > This seems to caused by a lack of handling for teams with no subscription. As a workaround, I added an active `Subscription` and set `customerId` to a random uuid for each `Team`. This created an organization for those teams during the migration. For example (one team with id=1): > > UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; > INSERT INTO "Subscription" ("planId", "priceId", "teamId", "updatedAt") VALUES ('temp', 'temp', 1, current_timestamp); This solved my issue, but now I'm seeing the following: <img width="1803" height="424" alt="Image" src="https://github.com/user-attachments/assets/59f6fc78-a9fd-4db3-a088-5ba09d4e75bf" />

kerem commented

2026-02-26 18:47:32 +03:00

Author

Owner

@seamon67 commented on GitHub (Jul 30, 2025):

Alright, I couldn't wait any longer.

In v1.11.1, you have to do these in your postgres container

UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp);

Thanks to @ad1217

Then you can upgrade to v1.12.1 There seems to be a lot of changes.

@pepicrft That's because you didn't do this.

@seamon67 commented on GitHub (Jul 30, 2025): > Alright, I couldn't wait any longer. > > In v1.11.1, you have to do these in your postgres container > > UPDATE "Team" SET "customerId"=gen_random_uuid() WHERE "customerId" is NULL; INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") VALUES ('ACTIVE', 'temp', 'temp', 1, current_timestamp); > > Thanks to [@ad1217](https://github.com/ad1217) > > Then you can upgrade to v1.12.1 There seems to be a lot of changes. @pepicrft That's because you didn't do this.

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@John-H-Smith commented on GitHub (Aug 16, 2025):

Same here. Any updates on that?

@John-H-Smith commented on GitHub (Aug 16, 2025): Same here. Any updates on that?

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@ephraimduncan commented on GitHub (Aug 23, 2025):

The migration fails because some teams don't have subscriptions, and the migration logic doesn't properly handle these "orphaned" teams. When the migration tries to create OrganisationGroup records for ALL teams, those without an assigned organisationId cause the constraint violation.

Backup your database before proceeding!

# Example backup command (adjust for your setup)
pg_dump -h localhost -U postgres documenso > backup_before_migration.sql

First, identify which teams don't have subscriptions:

SELECT id, name, "customerId" 
FROM "Team" 
WHERE id NOT IN (
    SELECT "teamId" 
    FROM "Subscription" 
    WHERE "teamId" IS NOT NULL
);

Run this SQL to create subscriptions for teams that don't have them:

-- Create active subscriptions for all teams without one
INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "customerId", "updatedAt") 
SELECT 
  'ACTIVE', 
  'free', 
  'free', 
  t.id,
  COALESCE(t."customerId", gen_random_uuid()::text),
  current_timestamp
FROM "Team" t
WHERE t.id NOT IN (
  SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL
)
AND t.id IS NOT NULL;

Confirm all teams now have subscriptions:

-- This should return 0
SELECT COUNT(*) as teams_without_subscription 
FROM "Team" t 
WHERE t.id NOT IN (
    SELECT "teamId" 
    FROM "Subscription" 
    WHERE "teamId" IS NOT NULL
);

Now you can safely upgrade to Documenso v1.12+. The migration should complete successfully.

This is temporary as we look at a better solution to migrate without loosing data.

@ephraimduncan commented on GitHub (Aug 23, 2025): The migration fails because some teams don't have subscriptions, and the migration logic doesn't properly handle these "orphaned" teams. When the migration tries to create OrganisationGroup records for ALL teams, those without an assigned `organisationId` cause the constraint violation. **Backup your database before proceeding!** ```bash # Example backup command (adjust for your setup) pg_dump -h localhost -U postgres documenso > backup_before_migration.sql ``` First, identify which teams don't have subscriptions: ```sql SELECT id, name, "customerId" FROM "Team" WHERE id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL ); ``` Run this SQL to create subscriptions for teams that don't have them: ```sql -- Create active subscriptions for all teams without one INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "customerId", "updatedAt") SELECT 'ACTIVE', 'free', 'free', t.id, COALESCE(t."customerId", gen_random_uuid()::text), current_timestamp FROM "Team" t WHERE t.id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL ) AND t.id IS NOT NULL; ``` Confirm all teams now have subscriptions: ```sql -- This should return 0 SELECT COUNT(*) as teams_without_subscription FROM "Team" t WHERE t.id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL ); ``` Now you can safely upgrade to Documenso v1.12+. The migration should complete successfully. This is temporary as we look at a better solution to migrate without loosing data.

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@crazyyzarc commented on GitHub (Sep 10, 2025):

Also…

2025-09-10 11:02:29.502 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2025-09-10 11:02:29.502 UTC [1] LOG: listening on IPv6 address "::", port 5432
2025-09-10 11:02:29.503 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025-09-10 11:02:29.506 UTC [30] LOG: database system was shut down at 2025-09-10 11:02:29 UTC
2025-09-10 11:02:29.510 UTC [1] LOG: database system is ready to accept connections
2025-09-10 11:03:40.465 UTC [98] ERROR: column Team.organisationId does not exist at character 139
2025-09-10 11:03:40.465 UTC [98] STATEMENT: SELECT "public"."Team"."id", "public"."Team"."name", "public"."Team"."url", "public"."Team"."createdAt", "public"."Team"."avatarImageId", "public"."Team"."organisationId", "public"."Team"."teamGlobalSettingsId" FROM "public"."Team" WHERE EXISTS(SELECT "t0"."teamId" FROM "public"."TeamGroup" AS "t0" LEFT JOIN "public"."OrganisationGroup" AS "j1" ON ("j1"."id") = ("t0"."organisationGroupId") WHERE (EXISTS(SELECT "t2"."groupId" FROM "public"."OrganisationGroupMember" AS "t2" LEFT JOIN "public"."OrganisationMember" AS "j3" ON ("j3"."id") = ("t2"."organisationMemberId") WHERE ("j3"."userId" = $1 AND ("j3"."id" IS NOT NULL) AND ("j1"."id") = ("t2"."groupId") AND "t2"."groupId" IS NOT NULL)) AND ("j1"."id" IS NOT NULL) AND ("public"."Team"."id") = ("t0"."teamId") AND "t0"."teamId" IS NOT NULL)) OFFSET $2

@crazyyzarc commented on GitHub (Sep 10, 2025): Also… `2025-09-10 11:02:29.502 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432` `2025-09-10 11:02:29.502 UTC [1] LOG: listening on IPv6 address "::", port 5432` `2025-09-10 11:02:29.503 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"` `2025-09-10 11:02:29.506 UTC [30] LOG: database system was shut down at 2025-09-10 11:02:29 UTC` `2025-09-10 11:02:29.510 UTC [1] LOG: database system is ready to accept connections` `2025-09-10 11:03:40.465 UTC [98] ERROR: column Team.organisationId does not exist at character 139` `2025-09-10 11:03:40.465 UTC [98] STATEMENT: SELECT "public"."Team"."id", "public"."Team"."name", "public"."Team"."url", "public"."Team"."createdAt", "public"."Team"."avatarImageId", "public"."Team"."organisationId", "public"."Team"."teamGlobalSettingsId" FROM "public"."Team" WHERE EXISTS(SELECT "t0"."teamId" FROM "public"."TeamGroup" AS "t0" LEFT JOIN "public"."OrganisationGroup" AS "j1" ON ("j1"."id") = ("t0"."organisationGroupId") WHERE (EXISTS(SELECT "t2"."groupId" FROM "public"."OrganisationGroupMember" AS "t2" LEFT JOIN "public"."OrganisationMember" AS "j3" ON ("j3"."id") = ("t2"."organisationMemberId") WHERE ("j3"."userId" = $1 AND ("j3"."id" IS NOT NULL) AND ("j1"."id") = ("t2"."groupId") AND "t2"."groupId" IS NOT NULL)) AND ("j1"."id" IS NOT NULL) AND ("public"."Team"."id") = ("t0"."teamId") AND "t0"."teamId" IS NOT NULL)) OFFSET $2`

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@KarloDerEchte commented on GitHub (Sep 18, 2025):

Having the same issue, we need a proper guide on how to do updates

@KarloDerEchte commented on GitHub (Sep 18, 2025): Having the same issue, we need a proper guide on how to do updates

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@david-loe commented on GitHub (Sep 24, 2025):

@ephraimduncan thanks for your instructions, there are 2 pitfalls:

customerId doesn't exist on Subscription on v1.11

ERROR:  column "customerId" of relation "Subscription" does not exist
LINE 1: ...iption" ("status", "planId", "priceId", "teamId", "customerI...
                                                             ^

If you have multiple teams inserting free as planId fails, bc it has to be unique

ERROR:  duplicate key value violates unique constraint "Subscription_planId_key"
DETAIL:  Key ("planId")=(free) already exists.

I did it this way:

UPDATE "Team" SET "customerId"=gen_random_uuid()::text WHERE "customerId" IS NULL;

INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") 
SELECT 
  'ACTIVE', 
  gen_random_uuid()::text, 
  'free', 
  t.id,
  current_timestamp
FROM "Team" t
WHERE t.id NOT IN (
  SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL
)
AND t.id IS NOT NULL;

and dont forget to mark the failed migration as rolled-back if not already done (in documenso container):

npx prisma migrate resolve --rolled-back "20250522054050_add_organisations" --schema ../../packages/prisma/schema.prisma

@david-loe commented on GitHub (Sep 24, 2025): @ephraimduncan thanks for your instructions, there are 2 pitfalls: 1. `customerId` doesn't exist on `Subscription` on `v1.11` ``` ERROR: column "customerId" of relation "Subscription" does not exist LINE 1: ...iption" ("status", "planId", "priceId", "teamId", "customerI... ^ ``` 2. If you have multiple teams inserting `free` as `planId` fails, bc it has to be unique ``` ERROR: duplicate key value violates unique constraint "Subscription_planId_key" DETAIL: Key ("planId")=(free) already exists. ``` --- I did it this way: ``` UPDATE "Team" SET "customerId"=gen_random_uuid()::text WHERE "customerId" IS NULL; ``` ``` INSERT INTO "Subscription" ("status", "planId", "priceId", "teamId", "updatedAt") SELECT 'ACTIVE', gen_random_uuid()::text, 'free', t.id, current_timestamp FROM "Team" t WHERE t.id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL ) AND t.id IS NOT NULL; ``` and dont forget to mark the failed migration as `rolled-back` if not already done (in documenso container): ``` npx prisma migrate resolve --rolled-back "20250522054050_add_organisations" --schema ../../packages/prisma/schema.prisma ```

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@lesofl commented on GitHub (Oct 7, 2025):

I've followed all the steps in this thread and rolled back the migration but absolutely cannot get it to work. I have confirmed that all the teams have subscriptions but get the exact same error.

very confused as to what is happening here - a proper guide on how to fix this issue would be ideal. for now I've gone back to v1.11.1 but wasted about 3 hours just trying to figure out why the error never resolves.

-- This returns 0 SELECT COUNT(*) as teams_without_subscription FROM "Team" t WHERE t.id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL );

-- Output of Teams SELECT * FROM "TEAM";

name	url	createdAt	customerId	id	ownerUserId
Personal Team	UUID	2025-10-07 22:30:16.325	UUID	1	1
Personal Team	UUID	2025-10-07 22:30:16.325	UUID	2	2
Personal Team	UUID	2025-10-07 22:30:16.325	UUID	3	3

--Output of Subscriptions

id	status	planId	priceId	createdAt	updatedAt	cancelAtPeriodEnd	teamId
3	ACTIVE	UUID	free	2025-10-07 22:31:40.771	2025-10-07 22:31:40.771	false	1
4	ACTIVE	UUID	free	2025-10-07 22:31:40.771	2025-10-07 22:31:40.771	false	2
5	ACTIVE	UUID	free	2025-10-07 22:31:40.771	2025-10-07 22:31:40.771	false	3

@lesofl commented on GitHub (Oct 7, 2025): I've followed all the steps in this thread and rolled back the migration but absolutely cannot get it to work. I have confirmed that all the teams have subscriptions but get the exact same error. very confused as to what is happening here - a proper guide on how to fix this issue would be ideal. for now I've gone back to v1.11.1 but wasted about 3 hours just trying to figure out why the error never resolves. `-- This returns 0 SELECT COUNT(*) as teams_without_subscription FROM "Team" t WHERE t.id NOT IN ( SELECT "teamId" FROM "Subscription" WHERE "teamId" IS NOT NULL );` `-- Output of Teams SELECT * FROM "TEAM"; ` |name|url|createdAt|customerId|id|ownerUserId|avatarImageId| |----|---|---------|----------|--|-----------|-------------| |Personal Team|UUID|2025-10-07 22:30:16.325|UUID|1|1|| |Personal Team|UUID|2025-10-07 22:30:16.325|UUID|2|2|| |Personal Team|UUID|2025-10-07 22:30:16.325|UUID|3|3|| `--Output of Subscriptions` |id|status|planId|priceId|periodEnd|userId|createdAt|updatedAt|cancelAtPeriodEnd|teamId| |--|------|------|-------|---------|------|---------|---------|-----------------|------| |3|ACTIVE|UUID|free|||2025-10-07 22:31:40.771|2025-10-07 22:31:40.771|false|1| |4|ACTIVE|UUID|free|||2025-10-07 22:31:40.771|2025-10-07 22:31:40.771|false|2| |5|ACTIVE|UUID|free|||2025-10-07 22:31:40.771|2025-10-07 22:31:40.771|false|3|

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@rachekalmir commented on GitHub (Nov 21, 2025):

I also got stuck with this one, but here is how I resolved it (this may or may not help you based on your exact data in the database):

I restored the documenso database onto a separate postgresql instance and ran through the organisations migration step by step to see where it was failing (after following above instructions to add the subscriptions for each team): https://github.com/documenso/documenso/blob/main/packages/prisma/migrations/20250522054050_add_organisations/migration.sql

Mine was failing on lines 601-634, where by I only had subscriptions attached to teams and no user subscriptions.

Thus I ran the following SQL to add a user subscription for the first user you create in the database (user 3) so that it could proceed past this point: INSERT INTO "Subscription" ("status", "planId", "priceId", "userId", "updatedAt") SELECT 'ACTIVE', gen_random_uuid()::text, 'free', 3, current_timestamp;

@rachekalmir commented on GitHub (Nov 21, 2025): I also got stuck with this one, but here is how I resolved it (this may or may not help you based on your exact data in the database): I restored the documenso database onto a separate postgresql instance and ran through the organisations migration step by step to see where it was failing (after following above instructions to add the subscriptions for each team): https://github.com/documenso/documenso/blob/main/packages/prisma/migrations/20250522054050_add_organisations/migration.sql Mine was failing on lines 601-634, where by I only had subscriptions attached to teams and no user subscriptions. Thus I ran the following SQL to add a user subscription for the first user you create in the database (user 3) so that it could proceed past this point: `INSERT INTO "Subscription" ("status", "planId", "priceId", "userId", "updatedAt") SELECT 'ACTIVE', gen_random_uuid()::text, 'free', 3, current_timestamp;`

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@mx4k commented on GitHub (Dec 18, 2025):

I would really appreciate if someone could provide a step by step guide for users with no furhter knowledge with SQL.

@mx4k commented on GitHub (Dec 18, 2025): I would really appreciate if someone could provide a step by step guide for users with no furhter knowledge with SQL.

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@saschafoerster commented on GitHub (Dec 29, 2025):

I played around with the commands here and used AI and in the end it somehow worked. 😅

@saschafoerster commented on GitHub (Dec 29, 2025): I played around with the commands here and used AI and in the end it somehow worked. 😅

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@crazyyzarc commented on GitHub (Jan 5, 2026):

Delete Team-Accounts w/o subscription and it works

@crazyyzarc commented on GitHub (Jan 5, 2026): Delete Team-Accounts w/o subscription and it works

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@mx4k commented on GitHub (Jan 14, 2026):

Delete Team-Accounts w/o subscription and it works

Can you please show how you did it?

@mx4k commented on GitHub (Jan 14, 2026): > Delete Team-Accounts w/o subscription and it works Can you please show how you did it?

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@giniwproductions-88 commented on GitHub (Feb 22, 2026):

I reproduced and fully resolved this — migrated a self-hosted instance from v1.8.1 → v2.6.0 with all 17 pending migrations applied and data intact.
Note: the workaround floating around (inserting a fake Subscription) does not work. The root cause is deeper than a missing Subscription record.
If you're stuck on this and need help upgrading, reach out: giniwproductions@gmail.com

@giniwproductions-88 commented on GitHub (Feb 22, 2026): I reproduced and fully resolved this — migrated a self-hosted instance from v1.8.1 → v2.6.0 with all 17 pending migrations applied and data intact. Note: the workaround floating around (inserting a fake Subscription) does not work. The root cause is deeper than a missing Subscription record. If you're stuck on this and need help upgrading, reach out: giniwproductions@gmail.com

kerem commented

2026-02-26 18:47:33 +03:00

Author

Owner

@bigbeka commented on GitHub (Feb 23, 2026):

@giniwproductions-88 could you please describe the solution here?

@bigbeka commented on GitHub (Feb 23, 2026): @giniwproductions-88 could you please describe the solution here?

kerem referenced this issue

2026-02-26 19:31:34 +03:00

[PR #547] [MERGED] fix: bypass signature fix (#536) #1037

Rows
Columns

[GH-ISSUE #1880] Failing Migrations when upgrading from 1.11 to 1.12/1.12.1 (docker) #547

Issue Description

Steps to Reproduce

Expected Behavior

Current Behavior

Screenshots (optional)

Operating System [e.g., Windows 10]

Browser [e.g., Chrome, Firefox]

Version [e.g., 2.0.1]

Please check the boxes that apply to this issue report.