fix: add missing orgId column to issued_oid4vc_credentials table#1615
fix: add missing orgId column to issued_oid4vc_credentials table#1615sagarkhole4 wants to merge 1 commit into
Conversation
Signed-off-by: Sagar Khole <sagar.khole@ayanworks.com>
📝 WalkthroughWalkthroughThis PR introduces two sequential database migrations that establish organization ownership relationships. The first migration adds ChangesOrganization Schema Extensions
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Microsoft Presidio Analyzer (2.2.362)libs/prisma-service/prisma/migrations/20260504110536_add_orgid_and_isprimary_in_oidc_issuer/migration.sqlMicrosoft Presidio Analyzer failed to scan this file Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@libs/prisma-service/prisma/migrations/20260504110536_add_orgid_and_isprimary_in_oidc_issuer/migration.sql`:
- Line 8: The IF guard that checks for the FK named 'oidc_issuer_orgId_fkey' is
not schema-scoped and can be fooled by identical constraint names in other
schemas; update the EXISTS query in migration.sql to restrict pg_constraint by
connamespace to the intended schema (e.g. add "AND connamespace = (SELECT oid
FROM pg_namespace WHERE nspname = 'public')" or use the actual target schema
name or current_schema() if appropriate) so the guard only detects the
constraint in the correct schema before creating the FK.
In
`@libs/prisma-service/prisma/migrations/20260507140000_add_orgId_to_issued_credentials/migration.sql`:
- Line 7: The IF NOT EXISTS guards query pg_constraint and pg_class by name
only, which can return false positives across schemas; modify both checks to
join pg_namespace and filter on the intended schema (e.g., JOIN pg_namespace n
ON n.oid = pg_constraint.connamespace WHERE pg_constraint.conname =
'issued_oid4vc_credentials_orgId_fkey' AND n.nspname = '<target_schema>' and
similarly for pg_class: JOIN pg_namespace n ON n.oid = c.relnamespace WHERE
c.relname = 'idx_issued_oid4vc_credentials_signingAid' AND n.nspname =
'<target_schema>'); replace '<target_schema>' with the actual schema used in
this migration so the constraint/index creation only skips when the object
exists in the same schema.
- Line 8: Migration uses ON DELETE RESTRICT for the nullable orgId FK which
prevents deleting organisations; update the foreign key constraint in the
migration that defines issued_oid4vc_credentials_orgId_fkey on table
issued_oid4vc_credentials so it uses ON DELETE SET NULL (matching the
oidc_issuer companion migration) instead of ON DELETE RESTRICT, ensuring the
orgId column is set to NULL when the referenced organisation.id is deleted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 195d7e1e-c6a4-4bd8-a28f-c7d0435518fe
📒 Files selected for processing (2)
libs/prisma-service/prisma/migrations/20260504110536_add_orgid_and_isprimary_in_oidc_issuer/migration.sqllibs/prisma-service/prisma/migrations/20260507140000_add_orgId_to_issued_credentials/migration.sql
| ALTER TABLE "oidc_issuer" ADD CONSTRAINT "oidc_issuer_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE SET NULL ON UPDATE CASCADE; | ||
| DO $$ | ||
| BEGIN | ||
| IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'oidc_issuer_orgId_fkey') THEN |
There was a problem hiding this comment.
Same pg_constraint schema-filter gap as the companion migration.
SELECT 1 FROM pg_constraint WHERE conname = 'oidc_issuer_orgId_fkey' does not filter by schema. An identically-named constraint in any other schema will cause the guard to skip creating the FK in the intended schema. Apply the same schema-scoped fix suggested in the companion file.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@libs/prisma-service/prisma/migrations/20260504110536_add_orgid_and_isprimary_in_oidc_issuer/migration.sql`
at line 8, The IF guard that checks for the FK named 'oidc_issuer_orgId_fkey' is
not schema-scoped and can be fooled by identical constraint names in other
schemas; update the EXISTS query in migration.sql to restrict pg_constraint by
connamespace to the intended schema (e.g. add "AND connamespace = (SELECT oid
FROM pg_namespace WHERE nspname = 'public')" or use the actual target schema
name or current_schema() if appropriate) so the guard only detects the
constraint in the correct schema before creating the FK.
| -- AddForeignKey | ||
| DO $$ | ||
| BEGIN | ||
| IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'issued_oid4vc_credentials_orgId_fkey') THEN |
There was a problem hiding this comment.
pg_constraint / pg_class lookups missing schema filter — can produce false positives in multi-schema databases.
Both guards search by name only:
SELECT 1 FROM pg_constraint WHERE conname = '...'
SELECT 1 FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = '...'In a database with multiple schemas, if an identically-named constraint or index exists in any schema (e.g., a test schema), the IF NOT EXISTS guard will evaluate to true and silently skip creating the constraint/index in the intended schema.
🔧 Proposed fix — scope checks to the target schema
- IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'issued_oid4vc_credentials_orgId_fkey') THEN
+ IF NOT EXISTS (
+ SELECT 1 FROM pg_constraint con
+ JOIN pg_class cls ON cls.oid = con.conrelid
+ JOIN pg_namespace nsp ON nsp.oid = cls.relnamespace
+ WHERE con.conname = 'issued_oid4vc_credentials_orgId_fkey'
+ AND nsp.nspname = current_schema()
+ ) THEN- IF NOT EXISTS (SELECT 1 FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = 'issued_oid4vc_credentials_orgId_issuanceSessionId_idx') THEN
+ IF NOT EXISTS (SELECT 1 FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = 'issued_oid4vc_credentials_orgId_issuanceSessionId_idx' AND n.nspname = current_schema()) THENAlso applies to: 15-15
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@libs/prisma-service/prisma/migrations/20260507140000_add_orgId_to_issued_credentials/migration.sql`
at line 7, The IF NOT EXISTS guards query pg_constraint and pg_class by name
only, which can return false positives across schemas; modify both checks to
join pg_namespace and filter on the intended schema (e.g., JOIN pg_namespace n
ON n.oid = pg_constraint.connamespace WHERE pg_constraint.conname =
'issued_oid4vc_credentials_orgId_fkey' AND n.nspname = '<target_schema>' and
similarly for pg_class: JOIN pg_namespace n ON n.oid = c.relnamespace WHERE
c.relname = 'idx_issued_oid4vc_credentials_signingAid' AND n.nspname =
'<target_schema>'); replace '<target_schema>' with the actual schema used in
this migration so the constraint/index creation only skips when the object
exists in the same schema.
| DO $$ | ||
| BEGIN | ||
| IF NOT EXISTS (SELECT 1 FROM pg_constraint WHERE conname = 'issued_oid4vc_credentials_orgId_fkey') THEN | ||
| ALTER TABLE "issued_oid4vc_credentials" ADD CONSTRAINT "issued_oid4vc_credentials_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE RESTRICT ON UPDATE CASCADE; |
There was a problem hiding this comment.
ON DELETE RESTRICT blocks org deletion — consider ON DELETE SET NULL for consistency and operability.
orgId is nullable in this table, yet the FK uses ON DELETE RESTRICT. This means any org with at least one linked issued credential can never be deleted — the DELETE will be rejected with a FK violation. The companion migration for oidc_issuer uses ON DELETE SET NULL, which is the natural choice for a nullable FK.
If org deletion should remain blocked while credentials exist, this is intentional; otherwise:
🔧 Proposed fix — change to `ON DELETE SET NULL`
- ALTER TABLE "issued_oid4vc_credentials" ADD CONSTRAINT "issued_oid4vc_credentials_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE RESTRICT ON UPDATE CASCADE;
+ ALTER TABLE "issued_oid4vc_credentials" ADD CONSTRAINT "issued_oid4vc_credentials_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE SET NULL ON UPDATE CASCADE;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ALTER TABLE "issued_oid4vc_credentials" ADD CONSTRAINT "issued_oid4vc_credentials_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE RESTRICT ON UPDATE CASCADE; | |
| ALTER TABLE "issued_oid4vc_credentials" ADD CONSTRAINT "issued_oid4vc_credentials_orgId_fkey" FOREIGN KEY ("orgId") REFERENCES "organisation"("id") ON DELETE SET NULL ON UPDATE CASCADE; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@libs/prisma-service/prisma/migrations/20260507140000_add_orgId_to_issued_credentials/migration.sql`
at line 8, Migration uses ON DELETE RESTRICT for the nullable orgId FK which
prevents deleting organisations; update the foreign key constraint in the
migration that defines issued_oid4vc_credentials_orgId_fkey on table
issued_oid4vc_credentials so it uses ON DELETE SET NULL (matching the
oidc_issuer companion migration) instead of ON DELETE RESTRICT, ensuring the
orgId column is set to NULL when the referenced organisation.id is deleted.
1 participant
Summary by CodeRabbit