Twenty 2.9.0 — blank page after update: frontend queries GaugeChartConfiguration, a type the 2.9.0 server schema doesn't expose

[marceau_t]

After the package update to Twenty 2.9.0, the app no longer loads — blank page in the browser.
The server side is healthy and fully on 2.9.0:

yarn command:prod upgrade:status → Instance 2.9.0 and the single workspace 2.9.0, both Up to date, 0 workspaces failed.
Server logs: [NestApplication] Nest application successfully started, all routes mapped, healthcheck green after boot (0 ECONNREFUSED once started), BullMQ worker processing jobs, no 500s and no GraphQL errors server-side.

The failure is frontend-only. At app load, the browser console throws:

Uncaught (in promise) CombinedGraphQLErrors: Unknown type "GaugeChartConfiguration".
Did you mean "BarChartConfiguration", "LineChartConfiguration", "PieChartConfiguration",
"AggregateChartConfiguration", or "CalendarConfiguration"?
  at /assets/index-CGzHeZZA.js

So the shipped frontend bundle queries a GraphQL type (GaugeChartConfiguration) that the 2.9.0 server schema does not define the package's front and server look built against different schemas.

Already tried, no effect:

• Reproduced in a clean private/incognito window → rules out browser cache.
• yarn command:prod cache:flush + restart → same error.
• App Repair → same error.

The only thing that would restore a working UI is rolling back to the pre-2.9.0 backup, which loses ~3 days of data, so I'd rather not.

Questions:
Is this a known front/server mismatch in the 2.9.0 package?
Is a corrected 2.9.x already available, or coming?
Is there a supported way to realign the frontend bundle with the server without a full rollback?

[james]

Hello @marceau_t and welcome to the Cloudron forum

Can you please send the output of cloudron-support --troubleshoot as well so we have more data to analyse the issue?

[james]

Hello @marceau_t
I was not able to reproduce this issue from installing Twenty Cloudron package version 0.14.0=>twenty 2.8.0 to 1.0.0=>twenty 2.9.0

[marceau_t]

Hi @james,
Here is the output :

Vendor: QEMU Product: Standard PC (i440FX + PIIX, 1996)
Linux: 6.8.0-124-generic
Ubuntu: noble 24.04
Cloudron: 9.2.0
Execution environment: kvm
Processor: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
BIOS pc-i440fx-8.1  CPU @ 2.0GHz x 2
RAM: 4009860KB
Disk: /dev/sda1        18G
[OK]	Root disk usage is OK (47%)
[OK]	Memory usage is OK (52%)
[OK]	Clock is NTP-synchronized
[OK]	node version is correct
[OK]	IPv6 is enabled in kernel. No public IPv6 address
[OK]	docker is running
[OK]	docker version is correct
[OK]	MySQL is running
[OK]	netplan is good
[OK]	DNS is resolving via systemd-resolved
[OK]	unbound is running
[OK]	IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[SKIP]	IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip — no public IPv6 address
[OK]	IPv4 HTTPS to auth.docker.io/token
[SKIP]	IPv6 HTTPS to auth.docker.io/token — no public IPv6 address
[OK]	IPv4 HTTPS to acme-v02.api.letsencrypt.org
[SKIP]	IPv6 HTTPS to acme-v02.api.letsencrypt.org — no public IPv6 address
[OK]	nginx is running
[OK]	dashboard cert is valid
[OK]	dashboard is reachable via loopback
[OK]	No pending database migrations
[WARN]	Service 'mysql' is not running (may be lazy-stopped)
[OK]	Service 'postgresql' is running and healthy
[WARN]	Service 'mongodb' is not running (may be lazy-stopped)
[OK]	Service 'mail' is running and healthy
[OK]	Service 'graphite' is running and healthy
[OK]	Service 'sftp' is running and healthy
[OK]	box v9.2.0 is running
[OK]	Dashboard is reachable via IPv4 (https://xxx)
[SKIP]	Dashboard IPv6 reachability — no public IPv6 address
[SKIP]	Domain expiry check — whois did not return an expiry date for 

======== Summary ========
PASS:  24
WARN:  2
FAIL:  0
SKIP:  5

Warnings:
  - Service 'mysql' is not running (may be lazy-stopped)
  - Service 'mongodb' is not running (may be lazy-stopped)

For troubleshooting tips, see https://docs.cloudron.io/troubleshooting
To share a full diagnostic dump on the forum, run: cloudron-support --send-diagnostics

[marceau_t]

Thanks for testing, that's actually my exact path. My instance was installed fresh as package v0.14.0 (Twenty 2.8.0) on May 29, then auto-updated v0.14.0 → v1.0.0 (2.9.0) on June 7 at 01:00. So same package versions and same Twenty versions as your repro.
The only difference left is data: yours is a clean install, mine had ~9 days of real data created under 2.8.0 (contacts, deals, and possibly a default dashboard/widget). I never manually created a chart, but a default dashboard widget referencing GaugeChartConfiguration could have been seeded under 2.8.0.
Could you share a SQL query to check whether any stored dashboard widget / chart configuration references GaugeChartConfiguration? If that's the culprit, I'd much rather delete that specific record than roll back the whole instance and lose 3 days of data.

[james]

Hello @marceau_t
This sound like an upstream issue.
You should create a GitHub issue with the details.

[marceau_t]

Alright thanks

[marceau_t]

@james I have some news
The update refreshed the server to 2.9.0 in /app/code, but the prebuilt frontend in the persistent volume /app/data/twenty-front was never re-synced — it still held the original 0.14.0 front from install (files dated from install day; index.html still pointing to the old bundle index-CGzHeZZA.js).
That stale bundle queries GaugeChartConfiguration, a type removed server-side in 2.3. So a 2.8.0-era front was served against a 2.9.0 schema → Unknown type "GaugeChartConfiguration" → blank page on load.

Confirmed: the string is present in /app/data/twenty-front/assets/ but absent from the fresh package front in /app/code/packages/twenty-server/dist/front.orig/assets/ (different hashes).

Fix: copied assets/, images/, manifest.json, index.html from dist/front.orig/ → /app/data/twenty-front/ (keeping the .env symlink), then restarted. App works.

Hope this helps

[james]

Hello @marceau_t
Thank you for this investigation.
Maybe you can help us with some insights.
Is /app/data/twenty-front/ something where users, like you, upload files that should be persistent?
I am leaning towards copying /app/code/packages/twenty-server/dist/front.orig on every app start to /run/twenty-front to fix this issue.
Since if there is nothing backup worthy, it should not even exist in /app/data/