Description of the bug
On a fresh SQLite deployment (the documented default), the API cache warmer fails on startup with a Prisma parameter-count error while creating the system config. Because the error throws during the boot sequence, the HTTP server never binds — the container never becomes healthy and sits in a restart loop.
Setting ENABLE_CACHE_WARMING=false lets the server boot normally, which isolates the fault to the warming path's system-config write on SQLite specifically.
Likely cause: "Too many parameter values were provided" is the Prisma error for a raw query ($executeRaw/$queryRaw) receiving more bind parameters than the SQL has placeholders. The system config stores a JSON blob, and the recent commit "cast config_data to jsonb in postgres user queries" handles this column Postgres-specifically — suggesting the system-config write was built around Postgres jsonb and the SQLite branch has a placeholder/parameter mismatch. Notably, the same "create system config" operation succeeds later in boot once warming is disabled, so the fault appears specific to the warmer's call into createSystemConfig rather than the config write in general.
Steps to reproduce
- Deploy v2.7.1 with SQLite (default DATABASE_URI=sqlite://addon/data/db.sqlite) and a healthy Redis.
- Leave cache warming at its default (enabled).
- Start the container with a clean database.
- Observe startup logs: the warmer logs "Warming popular content from TMDB...", then errors on "Failed to create system config: Too many parameter values were provided".
- The HTTP listener never binds; healthchecks return connection refused and the container loops starting → unhealthy → restart.
- Set ENABLE_CACHE_WARMING=false and restart — server boots cleanly and the system config is created successfully.
Expected behavior
The cache warmer should create the system config successfully on SQLite (or fail gracefully without blocking the HTTP server from binding), so a fresh default install comes up healthy without needing to disable cache warming.
Environment
Self-hosted (Docker)
Server Logs / Browser Console Errors
[Database] ℹ Initialized sqlite database
[API-Cache-Warming] ℹ [API Cache Warming] Warming popular content from TMDB...
[API-Cache-Warming] ERROR [API Cache Warming] Failed to create system config: Too many parameter values were provided
[API-Cache-Warming] ERROR [API Cache Warming] Error warming popular content: Too many parameter values were provided
# After setting ENABLE_CACHE_WARMING=false — boots cleanly:
✔ [Server Startup] Server ready to accept requests
✔ Addon active and listening on port <port>
[API-Cache-Warming] ✔ [API Cache Warming] System config created with UUID: system-cache-warmer
Description of the bug
On a fresh SQLite deployment (the documented default), the API cache warmer fails on startup with a Prisma parameter-count error while creating the system config. Because the error throws during the boot sequence, the HTTP server never binds — the container never becomes healthy and sits in a restart loop.
Setting ENABLE_CACHE_WARMING=false lets the server boot normally, which isolates the fault to the warming path's system-config write on SQLite specifically.
Likely cause: "Too many parameter values were provided" is the Prisma error for a raw query ($executeRaw/$queryRaw) receiving more bind parameters than the SQL has placeholders. The system config stores a JSON blob, and the recent commit "cast config_data to jsonb in postgres user queries" handles this column Postgres-specifically — suggesting the system-config write was built around Postgres jsonb and the SQLite branch has a placeholder/parameter mismatch. Notably, the same "create system config" operation succeeds later in boot once warming is disabled, so the fault appears specific to the warmer's call into createSystemConfig rather than the config write in general.
Steps to reproduce
Expected behavior
The cache warmer should create the system config successfully on SQLite (or fail gracefully without blocking the HTTP server from binding), so a fresh default install comes up healthy without needing to disable cache warming.
Environment
Self-hosted (Docker)
Server Logs / Browser Console Errors