Docker Compose Upgrade to 0.34 breaks Redirect

[chrisjenx]

Bug Description

Upgrade to 0.34.0 from 0.33.7 breaks redirect, i.e. https://twenty.domain.com will redirect to localhost/welcome instead of the set SERVER_URL in the .env file

Expected behavior

Should respect the .env SERVER_URL= setting for docker compose apps

Technical inputs

Followed upgrade instructions. docker compose down -> docker compose up -d
Everything is running and no errors in logs... guessing it's not reading the env file correctly?

[FelixMalfait]

Hey @chrisjenx thanks for trying out 0.34 so quickly. We'll get back to you with a solution tomorrow

[charlesBochet]

@chrisjenx @FelixMalfait the upgrade guide is missing, FRONT_DOMAIN, FRONT_PROTOCOL (and FRONT_PORT) need to be specified

[chrisjenx]

Ahh dang, OK I'll give that ago and report back!

[chrisjenx]

So yes, adding FRONT_DOMAIN and FRONT_PROTOCOL to .env and docker-compose fixes getting to the front end.

Looks like it doesn't auto migrate the database tho, we now get:

ApolloError: column Workspace.subdomain does not exist when trying to login with email/password

[kbkozlev]

I have the same issue.
Is "front_domain" the same as "server_url" and with protocol is it "https" or something else?

[FelixMalfait]

Hey @kbkozlev you can see examples at the top of this PR: https://github.com/twentyhq/twenty/pull/9034/files

Based on your feedback we've now made FRONT_DOMAIN/PROTOCOL optional (we just need to publish a new tag) and we fallback on the SERVER_URL if it isn't defined. That way we don't complexify the setup for most instances which have the same frontend/backend url

Thanks @chrisjenx for the report!

[chrisjenx]

Thanks! do you want a different ticket for the ApolloError: column Workspace.subdomain does not exist when trying to login with email/password error?

[chrisjenx]

Fixed, now get:

[FelixMalfait]

@chrisjenx that's strange because it should be in the entrypoint command when you restart the docker:

twenty/packages/twenty-docker/twenty/entrypoint.sh

Line 18 in 2ceb1c8

yarn database:migrate:prod

Can you check ENABLE_DB_MIGRATIONS's value maybe?

[chrisjenx]

@FelixMalfait

It's there, I can try running manually as well I guess

  server:
    image: twentycrm/twenty:${TAG}
    volumes:
      - server-local-data:/app/packages/twenty-server/${STORAGE_LOCAL_PATH:-.local-storage}
      - docker-data:/app/docker-data
    ports:
      - "3000:3000"
    environment:
      PORT: 3000
      PG_DATABASE_URL: postgres://${PGUSER_SUPERUSER:-postgres}:${PGPASSWORD_SUPERUSER:-twenty}@${PG_DATABASE_HOST:-db:5432}/default
      SERVER_URL: ${SERVER_URL}
      FRONT_BASE_URL: ${FRONT_BASE_URL:-$SERVER_URL}
      REDIS_URL: ${REDIS_URL:-redis://redis:6379}

      ENABLE_DB_MIGRATIONS: "true"

[araadt]

I know a +1 isn't super helpful, but I've got the same issue here. Currently troubleshooting on my side.

[FelixMalfait]

I've changed the default value for 0.34, maybe it will help others...

Also PG_DATABASE_HOST was incorrect in the .env.example (db:5432 instead of db).

@chrisjenx yes you should try to run it manually, but I'm not sure why it's not ran when starting the docker 🤔

[chrisjenx]

@FelixMalfait ran it manually working after a metadata issue see: #9041 (comment)

So I'm gussing there is an issue with migration not auto running on start inside the docker containers? Wondering if a race condition or it brings the containers up before finishing the migration?

[FelixMalfait]

Mmh strange, we'll see if there are other reports of this or if it's something related to your setup 🤔

[chrisjenx]

Yeah it is odd, I used the one line script to install on a clean vm, I'm surprised there's not more reports as I'm guessing thats probably the most common method to self host?