17.3.0 migration fails (group_details missing) when upgrading from 16.3.2 (works on 17.2.3)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start with the 20250929070310_add_view_all_principals_permission_to_existing_roles migration and run the provided Docker Compose seeder against the 16.3.2 database dump on 17.3.0. Compare the migration ordering around add_group_details with 17.2.3; done means the upgrade completes without the group_details error and the application starts.
Written by the indexing model from the issue text.
Description
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
- Start from a working 16.3.2 installation
- Dump database from PostgreSQL 13
- Restore into a fresh PostgreSQL 17 instance
- Use official Docker Compose setup
- Set:
TAG=17.3.0
POSTGRES_VERSION=17
- 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
- Dominant language
- Shell
- Stars
- 347
- Forks
- 319
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from opf/openproject-docker-compose
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
opf/openproject-docker-compose#150 · 6 comments · 5 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
All issues in opf/openproject-docker-compose
Similar issues
-
kind/bug/report meta/needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
docker-mailserver/docker-mailserver#4831 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bigbluebutton/docker#403 ·
-
Exif extensionOpen
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
getgrav/docker-grav#68 ·
-
Hyprland 0.57: monitor-workspaces reconcile errors on every start and reload when a named workspace exists (workspace.id is nil)Possibly taken @jasasonc claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
priority middle
Difficulty 1/5 Under an hour Newbie friendliness 62/100
KATO-Hiro/AtCoderClans#12940 ·
Maintainers usually reply within 1 day