github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-07-13 03:37:41 -05:00
Code Issues 1.6k Packages Projects Releases 79 Wiki Activity

[GH-ISSUE #3247] Pangolin 1.19.0 upgrade failed with missing SQLite column #30174

New Issue
Closed
opened 2026-06-13 10:42:43 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-06-13 10:42:43 -05:00
Owner
Copy Link

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:

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.

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.
GiteaMirror commented 2026-06-13 10:42:45 -05:00
Author
Owner
Copy Link

@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?
GiteaMirror commented 2026-06-13 10:42:46 -05:00
Author
Owner
Copy Link

@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'
}
<!-- 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' } ```
GiteaMirror commented 2026-06-13 10:42:47 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-06-13 10:42:48 -05:00
Author
Owner
Copy Link

@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
GiteaMirror commented 2026-06-13 10:42:49 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#30174
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?