Flush cache before and after upgrade for self-hosts

[ijreilly]

as per title

[ijreilly]

i find this is clearer but can revert if someone disagrees

[cubic-dev-ai]

No issues found across 2 files

[greptile-apps]

Greptile Overview

Greptile Summary

This PR updates the self-host Docker entrypoint to flush the application cache immediately before and after running yarn command:prod upgrade, and tweaks a related migration-runner log message to use “Upgrading workspace …”.

The change fits into the upgrade path for self-hosted deployments by ensuring cached metadata/state doesn’t survive across upgrades (which can otherwise cause stale reads during/after schema and workspace migrations).

Confidence Score: 4/5

• This PR is likely safe to merge with low risk, but a missing guard around the cache flush step could break startup on deployments where the cache backend isn’t configured.
• Changes are small and localized, but adding an unconditional cache flush in the entrypoint makes container startup sensitive to cache availability/CLI support. If cache:flush exits non-zero (e.g., cache disabled or misconfigured), set -e will stop the container before upgrade and before the app starts.
• packages/twenty-docker/twenty/entrypoint.sh

Important Files Changed

Filename	Overview
packages/twenty-docker/twenty/entrypoint.sh	Adds cache flush command immediately before and after yarn command:prod upgrade in the container entrypoint.
packages/twenty-server/src/database/commands/command-runners/workspaces-migration.command-runner.ts	Changes a log line to say “Upgrading workspace …” instead of “Running command on workspace …”; no behavior changes.

Sequence Diagram

sequenceDiagram
  participant Container as Docker entrypoint.sh
  participant DB as Postgres
  participant CLI as twenty-server CLI
  participant Cache as Cache/Redis

  Container->>DB: Check if schema 'core' exists (psql)
  alt core schema missing
    Container->>CLI: setup-db.ts
    Container->>CLI: database:migrate:prod
  end
  Container->>CLI: command:prod cache:flush
  CLI->>Cache: Flush cache keys
  Container->>CLI: command:prod upgrade
  CLI->>DB: Run upgrade/migrations per workspace
  CLI->>Cache: Read/write cache during upgrade
  Container->>CLI: command:prod cache:flush
  CLI->>Cache: Flush cache keys
  Container-->>Container: Continue startup (exec "$@")

Loading

[greptile-apps]

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Unconditional cache flush fails

Because this entrypoint runs with set -e, an unavailable/misconfigured cache backend (or a CLI that doesn’t support cache:flush in a given image/version) will cause yarn command:prod cache:flush to exit non‑zero and abort the container before upgrade and before startup. If this is intended only when cache is enabled, you likely need to make this step non-fatal (or gated similarly to the migrations toggles) so self-hosts without cache configured don’t end up in a crash loop.

[sentry]

Bug: The cache:flush command suppresses errors instead of propagating them. This can cause the entrypoint script to continue with a stale cache if flushing fails.
_{Severity: HIGH}

Suggested Fix

Modify FlushCacheCommand.run() to rethrow any caught exceptions. This will ensure the command exits with a non-zero status code upon failure, causing the set -e script to halt execution as intended.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: packages/twenty-docker/twenty/entrypoint.sh#L20-L22

Potential issue: The `yarn command:prod cache:flush` command, executed in the Docker
entrypoint script, can fail silently. The underlying `FlushCacheCommand.run()` method
catches all exceptions, such as those from Redis being unavailable, and logs them
without rethrowing. As a result, the command exits with a success code (0). Because the
entrypoint script uses `set -e`, it will not halt on this failure. The script will then
proceed with the upgrade process using a potentially stale cache, which could lead to
runtime errors or data inconsistencies after the upgrade completes.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[github-actions]

🚀 Preview Environment Ready!

Your preview environment is available at: http://bore.pub:51438

This environment will automatically shut down when the PR is closed or after 5 hours.

[twenty-eng-sync]

Hey @ijreilly! After you've done the QA of your Pull Request, you can mark it as done here. Thank you!