QueryFailedError: applicationRegistration.logoFileId does not exist when loading applications

[luisalrp]

Bug Description

On our self-hosted Twenty instance, application registrations cannot be loaded.

When the frontend executes the FindAllApplicationRegistrations GraphQL query, the backend generates a TypeORM query that selects:

"registration"."logoFileId"

from:

"core"."applicationRegistration"

PostgreSQL rejects the query because the logoFileId column does not exist:

QueryFailedError: column registration.logoFileId does not exist

The error occurs repeatedly whenever the application registrations list is requested.

Relevant log excerpt:

query failed: SELECT
  ...
  "registration"."logoFileId" AS "registration_logoFileId",
  ...
FROM "core"."applicationRegistration" "registration"
WHERE "registration"."deletedAt" IS NULL
ORDER BY "registration_createdAt" DESC, "registration_id" ASC
LIMIT 25 OFFSET 0

error: column registration.logoFileId does not exist

QueryFailedError: column registration.logoFileId does not exist
    at PostgresQueryRunner.query
    at SelectQueryBuilder.loadRawResults
    at SelectQueryBuilder.executeEntitiesAndRawResults
    at SelectQueryBuilder.getManyAndCount
    at ApplicationRegistrationService.findAll

PostgreSQL error code: 42703
PostgreSQL routine: errorMissingColumn

GraphQL operation:
FindAllApplicationRegistrations

Steps to reproduce:

1. Start Twenty using an existing PostgreSQL database.
2. Sign in to the workspace.
3. Open the page that loads the application registrations, such as Settings → Admin Panel → Applications.
4. Observe that the applications are not loaded.
5. Click on Synchronize catalog button.
6. Check the server logs and observe the missing-column error.

Expected behavior

The application registrations query should complete successfully and the applications page should display the available registrations.

Any required database upgrade command should create core.applicationRegistration.logoFileId before the updated server starts querying that column.

Technical inputs

• The NestJS application starts successfully, but ApplicationRegistrationService.findAll fails when TypeORM queries the application registrations.
• PostgreSQL returns error code 42703, indicating that a referenced column does not exist.
• The generated query expects core.applicationRegistration.logoFileId, but the deployed database schema does not contain that column.
• PR Resolve application registration logo and gallery image urls at query time #22827 introduced the logoFileId column on applicationRegistration through a Twenty 2.21 fast instance command:
  2-21-instance-command-fast-1783945979243-add-logo-file-id-to-application-registration.ts
• This may indicate that the server code and PostgreSQL schema are out of sync, or that the corresponding instance upgrade command was not executed or did not complete.
• Similar missing-column issues after version changes have previously been reported in Missing logoFileId column in WorkspaceEntity after upgrading from 1.17 to 1.18.1 #18324, column WorkspaceEntity.logoFileId does not exist #18162, and Login fails after upgrade to 2.20.0: column workspaceDiscoverability does not exist #22662.

Environment:

Twenty version/image tag: v2.23.2
Previous Twenty version: v2.21.2
Deployment method: Docker compose on Coolify
PostgreSQL version: postgres:16-alpine

[sonarly]

⚪ Sonarly Analysis — Resolved Severity

Schema drift blocks application registration loading

The applications settings query selects a column introduced by the deployed server, but that column is absent from the existing PostgreSQL schema. The resulting database error prevents application registrations and catalog synchronization from loading.

Root Cause

PostgreSQL schema drift caused the failure. The proximate cause is that ApplicationRegistrationEntity began declaring logoFileId and the logoFile relation, so TypeORM included "registration"."logoFileId" in the default application-registration query. Git blame attributes those declarations to commit 94192a2164058cedc9e21682791c45d077136314; the same commit also added the 2.21 fast instance command that executes:

ALTER TABLE "core"."applicationRegistration"
  ADD COLUMN IF NOT EXISTS "logoFileId" uuid

and then creates its unique constraint and foreign key [ref:git-show-94192a2164]. The reported PostgreSQL 42703 error proves that the deployed ORM metadata was active while the target database still lacked that column [ref:issue-23210].

The triggering state was the reported deployment of v2.23.2 against an existing database previously running v2.21.2. The new server code reached FindAllApplicationRegistrations and repeatedly queried the applicationRegistration entity, exposing the schema drift when the Applications page and catalog synchronization requested registrations. The repository proves the required command exists and is registered in the upgrade sequence; it does not prove that the command completed on this instance [ref:packages/twenty-server/src/database/commands/upgrade-version-command/2-21/2-21-instance-command-fast-1783945979243-add-logo-file-id-to-application-registration.ts].

The deployment path allows this inconsistent state to persist: the Docker entrypoint skips all database upgrades when DISABLE_DB_MIGRATIONS is true, and otherwise catches a failed yarn command:prod upgrade, logs a warning, and continues starting the server [ref:packages/twenty-docker/twenty/entrypoint.sh]. The upgrade runner aborts when an instance command fails, so a skipped, failed, or rolled-back upgrade can leave the application server running against an older schema [ref:packages/twenty-server/src/engine/core-modules/upgrade/services/upgrade-sequence-runner.service.ts]. The exact branch—migration disabled, migration failure, or migration not executed against the database used by the server—is not present in the issue evidence.

Blame commit: 94192a21 by martmull — Resolve application registration logo and gallery image urls at query time (#22827)

Suggested Fix

The exact fix is already implemented by commit cddeee5, which changes both Docker database startup scripts to treat upgrade failures as fatal and exit before starting the server.

---

Analyzed by Sonarly · View full analysis

[prastoin]

Thanks for reporting indeed, we're suffering from a PR merge race condition here. This should have been prevented from the CI already, will investigate root cause.
Fixing first with a patch on 2.23