17.3.0 migration fails (group_details missing) when upgrading from 16.3.2 (works on 17.2.3)

[hadifikri]

Environment

• Product: OpenProject
• Source version: 16.3.2
• Target version (failing): 17.3.0
• Target version (working): 17.2.3
• Deployment: official Docker Compose (openproject-docker-compose)
• Database: PostgreSQL
• Source DB: PostgreSQL 13
• Target DB: PostgreSQL 17 (via dump/restore)
• OS: Linux (Ubuntu)
• CPU: 4 cores

Summary

Upgrading from 16.3.2 → 17.3.0 fails during migrations with:

PG::UndefinedTable: relation "group_details" does not exist

Running the same upgrade path against 17.2.3 completes successfully.

This suggests a regression in 17.3.0 migration ordering or model usage during migration.

Steps to Reproduce

1. Start from a working 16.3.2 installation
2. Dump database from PostgreSQL 13
3. Restore into a fresh PostgreSQL 17 instance
4. Use official Docker Compose setup
5. Set:

TAG=17.3.0
POSTGRES_VERSION=17

6. Run:

docker compose run --rm seeder

Expected Behavior

All migrations complete successfully and application starts.

Actual Behavior

Migration fails at:

20250929070310_add_view_all_principals_permission_to_existing_roles

with error:

PG::UndefinedTable: ERROR: relation "group_details" does not exist

Relevant Logs

ActiveRecord::StatementInvalid: PG::UndefinedTable:
ERROR: relation "group_details" does not exist

(occurs during migration execution)

Additional Observations

• The same database dump:
  • ✅ Migrates successfully on 17.2.3
  • ❌ Fails on 17.3.0
• Earlier migration list shows add_group_details occurs after the failing migration, suggesting ordering or dependency issue.
• This occurs on a clean PostgreSQL 17 data directory, ruling out stale data.

Workaround

Downgrading to:

TAG=17.2.3

allows migration to complete successfully.

Suspected Cause

A migration in 17.3.0 references group_details before the table is created, possibly due to:

• incorrect migration ordering
• model loading referencing new schema prematurely
• missing dependency between migrations

Request

Please confirm:

• whether this is a known issue in 17.3.0
• if a fix is planned (e.g. 17.3.1)
• or recommended upgrade path/workaround

[Murazaki]

I had the exact same issue, the file seem to have been tampered with after the following migration files.

I solved the situation by deactivating the file manually, then running the migration of the rest, and then reactivating it to eventually migrate it.

# deactivate the migration file as root
docker compose run --rm -u root seeder mv db/migrate/20250929070310_add_view_all_principals_permission_to_existing_roles.rb db/migrate/.20250929070310_add_view_all_principals_permission_to_existing_roles.rb 

# migrate the database as app
docker compose run --rm -u app seeder bin/rails db:migrate

# reactivate the migration file as root
docker compose run --rm -u root seeder mv db/migrate/.20250929070310_add_view_all_principals_permission_to_existing_roles.rb db/migrate/20250929070310_add_view_all_principals_permission_to_existing_roles.rb 

# migrate the database as app
docker compose run --rm -u app seeder bin/rails db:migrate