Originally assigned to: @oschwartz10612 on GitHub.
Describe the Bug
After upgrading my self-hosted Pangolin instance from 1.18.4 to 1.19.0, Pangolin would not start.
The container logs showed this error:
SqliteError: no such column: "settingsEnableGlobalNewtAutoUpdate"
It looked like Pangolin thought the 1.19.0 migration had already finished, but the database was still missing at least one of the new columns from that migration.
I checked the SQLite database and saw 1.19.0 listed in versionMigrations, but the orgs table did not have settingsEnableGlobalNewtAutoUpdate.
I was able to recover by:
Backing up config/db/db.sqlite
Removing the 1.19.0 row from versionMigrations
Restarting Pangolin
After that, the 1.19.0 migration ran again and Pangolin started normally.
Environment
Pangolin Version: 1.19.0
Previous Pangolin Version: 1.18.4
Database: SQLite
Deployment: Docker Compose
Traefik: 3.7
Gerbil: 1.4.1
Newt: 1.13.0
To Reproduce
I don't have exact steps beyond the upgrade itself.
In my case:
Upgrade from 1.18.4 to 1.19.0
Pangolin fails to start
Logs show no such column: "settingsEnableGlobalNewtAutoUpdate"
Database has 1.19.0 in versionMigrations, but the column is missing from orgs
Expected Behavior
The upgrade should finish cleanly, or if the migration fails, Pangolin should be able to retry it on the next startup.
Originally created by @rinseaid on GitHub (Jun 12, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3247
Originally assigned to: @oschwartz10612 on GitHub.
### Describe the Bug
After upgrading my self-hosted Pangolin instance from 1.18.4 to 1.19.0, Pangolin would not start.
The container logs showed this error:
```text
SqliteError: no such column: "settingsEnableGlobalNewtAutoUpdate"
```
It looked like Pangolin thought the 1.19.0 migration had already finished, but the database was still missing at least one of the new columns from that migration.
I checked the SQLite database and saw `1.19.0` listed in `versionMigrations`, but the `orgs` table did not have `settingsEnableGlobalNewtAutoUpdate`.
I was able to recover by:
1. Backing up `config/db/db.sqlite`
2. Removing the `1.19.0` row from `versionMigrations`
3. Restarting Pangolin
After that, the 1.19.0 migration ran again and Pangolin started normally.
### Environment
- Pangolin Version: 1.19.0
- Previous Pangolin Version: 1.18.4
- Database: SQLite
- Deployment: Docker Compose
- Traefik: 3.7
- Gerbil: 1.4.1
- Newt: 1.13.0
### To Reproduce
I don't have exact steps beyond the upgrade itself.
In my case:
1. Upgrade from 1.18.4 to 1.19.0
2. Pangolin fails to start
3. Logs show `no such column: "settingsEnableGlobalNewtAutoUpdate"`
4. Database has `1.19.0` in `versionMigrations`, but the column is missing from `orgs`
### Expected Behavior
The upgrade should finish cleanly, or if the migration fails, Pangolin should be able to retry it on the next startup.
@oschwartz10612 commented on GitHub (Jun 12, 2026):
Hum you were coming from pure 1.18.4? Thats strange... When you updated did you quickly stop and start the container or anything that could have caused the migration to partiall run?
<!-- gh-comment-id:4686856041 -->
@oschwartz10612 commented on GitHub (Jun 12, 2026):
Hum you were coming from pure 1.18.4? Thats strange... When you updated did you quickly stop and start the container or anything that could have caused the migration to partiall run?
I am currently getting the same error coming from 1.18.4. No interruptions to the migration occurred. I did not need to drop any entries from my versionMigrations table after rolling back to 1.18.4 (no DB changes seemed to be made in my case).
Starting migrations from version 1.18.4
Migrations to run: 1.19.0, 1.19.1
Running migration 1.19.0
Running setup script 1.19.0...
Failed to migrate db: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Failed to run migration 1.19.0: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Migration process failed: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Error running migrations: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
<!-- gh-comment-id:4688040849 -->
@anzi-tech commented on GitHub (Jun 12, 2026):
I am currently getting the same error coming from 1.18.4. No interruptions to the migration occurred. I did not need to drop any entries from my versionMigrations table after rolling back to 1.18.4 (no DB changes seemed to be made in my case).
```
Starting migrations from version 1.18.4
Migrations to run: 1.19.0, 1.19.1
Running migration 1.19.0
Running setup script 1.19.0...
Failed to migrate db: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Failed to run migration 1.19.0: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Migration process failed: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
Error running migrations: SqliteError: NOT NULL constraint failed: targets.mode
at file:///app/dist/migrations.mjs:6065:9
at sqliteTransaction (/app/node_modules/better-sqlite3/lib/methods/transaction.js:65:24)
at Object.migration36 [as run] (file:///app/dist/migrations.mjs:6071:7)
at executeScripts (file:///app/dist/migrations.mjs:6578:27)
at async runMigrations (file:///app/dist/migrations.mjs:6535:7)
at async run (file:///app/dist/migrations.mjs:6508:3)
at async file:///app/dist/migrations.mjs:6506:1 {
code: 'SQLITE_CONSTRAINT_NOTNULL'
}
```
Hum you were coming from pure 1.18.4? Thats strange... When you updated did you quickly stop and start the container or anything that could have caused the migration to partiall run?
I don't think so - I think it was running about 10 minutes before I noticed and started the recovery.
<!-- gh-comment-id:4691518636 -->
@rinseaid commented on GitHub (Jun 12, 2026):
> Hum you were coming from pure 1.18.4? Thats strange... When you updated did you quickly stop and start the container or anything that could have caused the migration to partiall run?
I don't think so - I think it was running about 10 minutes before I noticed and started the recovery.
@oschwartz10612 commented on GitHub (Jun 12, 2026):
@anzi-tech I think this is a 2nd different issue which I will try to fix in the next patch
<!-- gh-comment-id:4694118415 -->
@oschwartz10612 commented on GitHub (Jun 12, 2026):
@anzi-tech I think this is a 2nd different issue which I will try to fix in the next patch
I looked further into my Doco-CD logs (how I'm deploying my Pangolin manifest) and noticed that the upgrade was waiting on the container healthcheck.
The deploy started at 2026-06-11 19:47:59 -04:00 and Doco-CD marked it failed at 2026-06-11 19:52:32 -04:00 with:
dependency failed to start: container pangolin is unhealthy
Doco-CD logged the elapsed time as 4m34.954s, then immediately restarted the Pangolin container as part of its reconciliation.
So it appears the container was stopped after about 4 minutes 35 seconds when the deployment controller restarted the unhealthy container.
<!-- gh-comment-id:4694320892 -->
@rinseaid commented on GitHub (Jun 12, 2026):
I looked further into my Doco-CD logs (how I'm deploying my Pangolin manifest) and noticed that the upgrade was waiting on the container healthcheck.
The deploy started at `2026-06-11 19:47:59 -04:00` and Doco-CD marked it failed at `2026-06-11 19:52:32 -04:00` with:
```
dependency failed to start: container pangolin is unhealthy
```
Doco-CD logged the elapsed time as `4m34.954s`, then immediately restarted the Pangolin container as part of its reconciliation.
So it appears the container was stopped after about 4 minutes 35 seconds when the deployment controller restarted the unhealthy container.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rinseaid on GitHub (Jun 12, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3247
Originally assigned to: @oschwartz10612 on GitHub.
Describe the Bug
After upgrading my self-hosted Pangolin instance from 1.18.4 to 1.19.0, Pangolin would not start.
The container logs showed this error:
It looked like Pangolin thought the 1.19.0 migration had already finished, but the database was still missing at least one of the new columns from that migration.
I checked the SQLite database and saw
1.19.0listed inversionMigrations, but theorgstable did not havesettingsEnableGlobalNewtAutoUpdate.I was able to recover by:
config/db/db.sqlite1.19.0row fromversionMigrationsAfter that, the 1.19.0 migration ran again and Pangolin started normally.
Environment
To Reproduce
I don't have exact steps beyond the upgrade itself.
In my case:
no such column: "settingsEnableGlobalNewtAutoUpdate"1.19.0inversionMigrations, but the column is missing fromorgsExpected Behavior
The upgrade should finish cleanly, or if the migration fails, Pangolin should be able to retry it on the next startup.
@oschwartz10612 commented on GitHub (Jun 12, 2026):
Hum you were coming from pure 1.18.4? Thats strange... When you updated did you quickly stop and start the container or anything that could have caused the migration to partiall run?
@anzi-tech commented on GitHub (Jun 12, 2026):
I am currently getting the same error coming from 1.18.4. No interruptions to the migration occurred. I did not need to drop any entries from my versionMigrations table after rolling back to 1.18.4 (no DB changes seemed to be made in my case).
@rinseaid commented on GitHub (Jun 12, 2026):
I don't think so - I think it was running about 10 minutes before I noticed and started the recovery.
@oschwartz10612 commented on GitHub (Jun 12, 2026):
@anzi-tech I think this is a 2nd different issue which I will try to fix in the next patch
@rinseaid commented on GitHub (Jun 12, 2026):
I looked further into my Doco-CD logs (how I'm deploying my Pangolin manifest) and noticed that the upgrade was waiting on the container healthcheck.
The deploy started at
2026-06-11 19:47:59 -04:00and Doco-CD marked it failed at2026-06-11 19:52:32 -04:00with:Doco-CD logged the elapsed time as
4m34.954s, then immediately restarted the Pangolin container as part of its reconciliation.So it appears the container was stopped after about 4 minutes 35 seconds when the deployment controller restarted the unhealthy container.