Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Fix unlinked auth profile/image relation after enabling module-migration inheritance

オープン
  • 何か問題がありますか？
#5,809 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
dart, postgresql, sql
領域
backend, databases

調査の方向性

Start by reading the UserProfile.image and UserProfileImage.userProfile relation definitions and the module-migration inheritance path used by consuming projects. Then trace how create-migration handles module SQL and non-breaking classifications, and identify coverage for upgrades of populated databases and transactional data-only restores. Done means the linked relation is migrated without data loss, consuming projects run the custom non-breaking SQL, and the regression scenarios pass.

索引モデルが issue の本文から書いたものです。

説明

area: authentication bug

Summary

Correct the unlinked relation between UserProfile.image and UserProfileImage.userProfile in serverpod_auth_core, without losing existing profile or image data.

Prerequisite: projects must use the SQL from module migrations rather than regenerating the module's schema changes with serverpod create-migration. This capability must be solved first so a custom, non-destructive module migration reaches consuming projects.

Background and root cause

The relation definitions omit the shared name parameter that would link the two sides:

# UserProfileImage
userProfile: UserProfile?, relation(onDelete=Cascade)

# UserProfile
image: UserProfileImage?, relation(optional, deferred)

This creates two independent foreign keys and an unintended circular reference:

  • serverpod_auth_core_profile.imageId references serverpod_auth_core_profile_image.id.
  • serverpod_auth_core_profile_image.userProfileId references serverpod_auth_core_profile.id.

The cycle broke data-only restores, as described in #5767. PR #5771 made the profile-image foreign-key check deferred to commit, allowing a transactional pg_restore to succeed. That was a workaround for restoration, not a correction of the missing relation name.

Why module-migration inheritance must come first

As explained in the linked discussion, adding the missing relation name under the current migration system produces a destructive schema migration that drops data. A custom SQL migration could preserve the existing data, but consuming projects currently regenerate module changes during create-migration instead of inheriting the module's migration SQL. Consequently, the custom data-preserving transformation would not reach those projects.

The prerequisite must:

  • Make project migrations inherit/use the SQL from the corresponding module migrations instead of rebuilding those changes solely from the schema diff.
  • Preserve custom module SQL, including transformations that turn a destructive generated migration into a non-destructive one.
  • Honor the module migration's non-breaking classification when creating the project migration.

The discussion also notes that the same limitation could affect future offline-sync metadata schema evolution, but that is supporting context rather than additional scope for this issue.

Proposed implementation order

  1. Solve module-migration inheritance for consuming projects, including preservation of custom SQL and non-breaking classification.
  2. Link UserProfile.image and UserProfileImage.userProfile using the appropriate shared relation name.
  3. Provide a custom, non-destructive module migration that preserves existing users, profiles, images, and their associations; verify that consuming projects actually execute it.

Acceptance criteria

  • The two model fields describe the intended linked relation rather than two accidentally independent relations.
  • Upgrading a consuming project preserves existing users, profiles, image records, and profile/image associations, including profiles without an image.
  • The consuming project's migration uses the module's custom SQL and honors its non-breaking classification.
  • Regression coverage exercises an existing populated database upgraded through the consuming-project migration path, not just a fresh module database.
  • The transactional data-only restore behavior fixed by #5771 remains working.

Initiative context and references

主要言語
Dart
スター
3.3k
フォーク
382
平均マージ
1日 3時間
マージ済み PR（30日）
62

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

serverpod/serverpod のほかの issue

serverpod/serverpod の issue をすべて見る

似ている issue

Dart の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。