github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 05:39:49 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #2327] Migration 1.15.0 fails to run, stuck with "no such column: requireDeviceApproval" #6935

New Issue
Closed
opened 2026-04-25 15:55:54 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-25 15:55:54 -05:00
Owner
Copy Link

Originally created by @Mevas on GitHub (Jan 25, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2327

Describe the Bug

Title: SQLite Migration 1.15.0 fails to run, stuck with "no such column: requireDeviceApproval"

Description:

When upgrading from 1.14.0 to 1.15.0, the migration fails silently and leaves the database in an inconsistent state. The app then continuously errors with:

SqliteError: no such column: "requireDeviceApproval" - should this be a string literal in single-quotes?

Root Cause:

On startup, the migration runner outputs:

Starting migrations from version 1.15.0
Migrations to run:
All migrations completed successfully

This indicates the upgrade check logic is broken. The versionMigrations table was empty, but the migration runner incorrectly determined that 1.15.0 was already the current version and skipped running the 1.15.0 migration. This leaves the database schema incomplete.

Note: Even manually setting APP_VERSION="0.14.1" when running the migration script doesn't work:

APP_VERSION="0.14.1" ENVIRONMENT=prod node dist/migrations.mjs
Starting migrations from version 1.15.0
Migrations to run:
All migrations completed successfully

The migration runner still reports "Starting migrations from version 1.15.0" despite the explicit environment variable, suggesting the version detection logic ignores APP_VERSION or has another source of truth.

Possible Issue:

It seems like fresh 1.14.1 deployments may not properly populate the versionMigrations table, causing subsequent upgrades to fail.

Workaround:

  1. Manually insert the missing 1.14.0 entry into the migrations table:

    # Inside the container or with direct sqlite3 access
sqlite3 /path/to/db/db.sqlite "INSERT INTO versionMigrations (version, executedAt) VALUES ('1.14.0', $(date +%s)000);"

  2. Run migrations manually:

    docker exec -it <container> sh -c "ENVIRONMENT=prod node dist/migrations.mjs"

  3. Verify 1.15.0 migration completed:

    sqlite3 /path/to/db/db.sqlite "SELECT * FROM versionMigrations;"

Environment

  • Docker deployment
  • SQLite database
  • Started with: 1.14.1 (fresh deployment)
  • Upgraded to: 1.15.0

To Reproduce

  1. Deploy fresh 1.14.0/1.14.1 instance (I started with 1.14.1 a few weeks ago)
  2. Upgrade to 1.15.0
  3. Start the app
  4. Check versionMigrations table — it's empty (or missing 1.14.0)
  5. App crashes with requireDeviceApproval column missing error
  6. Restarting shows the same "Migrations to run: [empty]" output

Expected Behavior

  • Fresh deployments should populate versionMigrations with the current version
  • Migration runner should correctly detect when migrations need to run
  • Failed migrations should not silently complete
Originally created by @Mevas on GitHub (Jan 25, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2327 ### Describe the Bug **Title:** SQLite Migration 1.15.0 fails to run, stuck with "no such column: requireDeviceApproval" **Description:** When upgrading from 1.14.0 to 1.15.0, the migration fails silently and leaves the database in an inconsistent state. The app then continuously errors with: ``` SqliteError: no such column: "requireDeviceApproval" - should this be a string literal in single-quotes? ``` **Root Cause:** On startup, the migration runner outputs: ``` Starting migrations from version 1.15.0 Migrations to run: All migrations completed successfully ``` This indicates the upgrade check logic is broken. The `versionMigrations` table was empty, but the migration runner incorrectly determined that 1.15.0 was already the current version and skipped running the 1.15.0 migration. This leaves the database schema incomplete. **Note:** Even manually setting `APP_VERSION="0.14.1"` when running the migration script doesn't work: ```bash APP_VERSION="0.14.1" ENVIRONMENT=prod node dist/migrations.mjs Starting migrations from version 1.15.0 Migrations to run: All migrations completed successfully ``` The migration runner still reports "Starting migrations from version 1.15.0" despite the explicit environment variable, suggesting the version detection logic ignores `APP_VERSION` or has another source of truth. **Possible Issue:** It seems like fresh 1.14.1 deployments may not properly populate the `versionMigrations` table, causing subsequent upgrades to fail. **Workaround:** 1. Manually insert the missing 1.14.0 entry into the migrations table: ```bash # Inside the container or with direct sqlite3 access sqlite3 /path/to/db/db.sqlite "INSERT INTO versionMigrations (version, executedAt) VALUES ('1.14.0', $(date +%s)000);" ``` 2. Run migrations manually: ```bash docker exec -it <container> sh -c "ENVIRONMENT=prod node dist/migrations.mjs" ``` 3. Verify 1.15.0 migration completed: ```bash sqlite3 /path/to/db/db.sqlite "SELECT * FROM versionMigrations;" ``` ### Environment - Docker deployment - SQLite database - Started with: 1.14.1 (fresh deployment) - Upgraded to: 1.15.0 ### To Reproduce 1. Deploy fresh 1.14.0/1.14.1 instance (I started with 1.14.1 a few weeks ago) 2. Upgrade to 1.15.0 3. Start the app 4. Check `versionMigrations` table — it's empty (or missing 1.14.0) 5. App crashes with `requireDeviceApproval` column missing error 6. Restarting shows the same "Migrations to run: [empty]" output ### Expected Behavior - Fresh deployments should populate `versionMigrations` with the current version - Migration runner should correctly detect when migrations need to run - Failed migrations should not silently complete
GiteaMirror commented 2026-04-25 15:55:55 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jan 26, 2026):

Hello. I think maybe somehow you got your DB into a weird state. I just tested this and was unable to replicate. After installing a fresh 1.14.1 and then bumping the image and restarting the container I got a successful migration:

pangolin  | Starting migrations from version 1.14.1
pangolin  | Migrations to run: 1.15.0
pangolin  | Running migration 1.15.0
pangolin  | Running setup script 1.15.0...
pangolin  | Migrated database
pangolin  | 1.15.0 migration complete
pangolin  | Successfully completed migration 1.15.0
pangolin  | All migrations completed successfully

On first run, if the versionMigrations table doesn’t exist, the setup code runs the initial migrations and then inserts the current APP_VERSION into versionMigrations. See:

            console.log("Migrations table does not exist, creating it...");
            console.log("Running migrations...");
            try {
                await migrate(db, {
                    migrationsFolder: path.join(__DIRNAME, "init") // put here during the docker build
                });
                console.log("Migrations completed successfully.");
            } catch (error) {
                console.error("Error running migrations:", error);
            }

            await db
                .insert(versionMigrations)
                .values({
                    version: appVersion,
                    executedAt: Date.now()
                })
                .execute();

Could you confirm if you are able to replicate the issue somehow reliably?

<!-- gh-comment-id:3797464225 --> @oschwartz10612 commented on GitHub (Jan 26, 2026): Hello. I think maybe somehow you got your DB into a weird state. I just tested this and was unable to replicate. After installing a fresh 1.14.1 and then bumping the image and restarting the container I got a successful migration: ``` pangolin | Starting migrations from version 1.14.1 pangolin | Migrations to run: 1.15.0 pangolin | Running migration 1.15.0 pangolin | Running setup script 1.15.0... pangolin | Migrated database pangolin | 1.15.0 migration complete pangolin | Successfully completed migration 1.15.0 pangolin | All migrations completed successfully ``` On first run, if the `versionMigrations` table doesn’t exist, the setup code runs the initial migrations and then inserts the current `APP_VERSION` into `versionMigrations`. See: ```pangolin/server/setup/migrationsPg.ts#L89-114 console.log("Migrations table does not exist, creating it..."); console.log("Running migrations..."); try { await migrate(db, { migrationsFolder: path.join(__DIRNAME, "init") // put here during the docker build }); console.log("Migrations completed successfully."); } catch (error) { console.error("Error running migrations:", error); } await db .insert(versionMigrations) .values({ version: appVersion, executedAt: Date.now() }) .execute(); ``` Could you confirm if you are able to replicate the issue somehow reliably?
GiteaMirror commented 2026-04-25 15:55:56 -05:00
Author
Owner
Copy Link

@Mevas commented on GitHub (Jan 26, 2026):

Oh, it was indeed installed through the proxmox helper scripts, as linked in the mention. This issue can safely be closed, as the issue seems to have been on their end - I hadn't even thought of that.

<!-- gh-comment-id:3801153915 --> @Mevas commented on GitHub (Jan 26, 2026): Oh, it was indeed installed through the proxmox helper scripts, as linked in the mention. This issue can safely be closed, as the issue seems to have been on their end - I hadn't even thought of that.
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#6935
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?