fix(organizations): allow organization name reuse after deletion

[PierreLeGuen]

Summary

Fixes #337 - Cannot Reuse Name of a Removed Organization

Problem

When creating a new organization with a name that was previously used by a removed/deleted organization, the POST /v1/organizations endpoint returns a 409 Conflict error: "Organization already exists".

This occurs because the organizations table uses soft deletion (is_active = false) but has a hard unique constraint on name that doesn't account for inactive organizations.

Solution

Replace the existing unique constraint with a partial unique index that only applies to active organizations:

CREATE UNIQUE INDEX unique_organization_name_active_only
ON organizations(name)
WHERE is_active = true;

This follows the established pattern used in V0012 for the models table's public_name constraint.

Changes

• Added migration V0040__fix_organization_name_unique_constraint.sql
• No application code changes required (repository queries already filter by is_active = true)

[gemini-code-assist]

Summary of Changes

Hello @PierreLeGuen, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical bug where organization names could not be reused after an organization was soft-deleted, leading to a 409 Conflict error. The solution involves a database schema migration that modifies the unique constraint on organization names to apply only to active organizations, ensuring that inactive organizations do not prevent the creation of new organizations with the same name. This change enhances the system's flexibility in managing organization lifecycles without requiring any application code modifications.

Highlights

• Database Schema Update: Replaced the existing hard unique constraint on organization names with a partial unique index that only applies to active organizations. This allows for the reuse of organization names after an organization has been soft-deleted.
• Bug Fix: Resolves the 409 Conflict error encountered when attempting to create a new organization with a name previously used by a soft-deleted organization.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request modifies the database migration script V0040__fix_organization_name_unique_constraint.sql to change the unique constraint on the organizations table's name column. The original constraint is dropped, and a new partial unique index unique_organization_name_active_only is created that only applies to active organizations (is_active = true). The review comment suggests using CREATE INDEX CONCURRENTLY to avoid locking the table during index creation, which could cause downtime, and also notes that this command cannot be executed within a transaction block.

[PierreLeGuen]

@claude review

[claude]

Code Review - PR #340

Acknowledgment of previous feedback: The critical issue from the previous review (missing IF EXISTS) has been addressed in commit 05bf341. That issue is now RESOLVED ✓

---

Analysis Summary

I've analyzed this PR focusing on critical issues. The changes implement a partial unique index for organization names to allow reuse after soft deletion. All previous concerns have been addressed.

What's Working Well

1. IF EXISTS added - Migration is now idempotent and production-safe (crates/database/src/migrations/sql/V0040__fix_organization_name_unique_constraint.sql:11)
2. Correct pattern - Matches V0012 migration for models table (proven approach)
3. CONCURRENTLY usage - Prevents table locking during production deployment
4. Comprehensive E2E test - New test validates the fix for issue Issue: Cannot Reuse Name of a Removed Organization #337 (lines 108-173 in e2e_duplicate_names.rs)
5. No application code changes - Repository queries already filter by is_active = true

Critical Issues Found

None - All critical issues from previous review have been resolved.

Rolling Deployment Safety ✓

This migration is safe for rolling deployments:

• ✅ DROP CONSTRAINT IF EXISTS - idempotent operation
• ✅ CREATE INDEX CONCURRENTLY - non-blocking, won't hold table locks
• ✅ No data migration or backfill required
• ✅ No breaking API changes
• ✅ Application code already compatible (filters on is_active)

Minor Observations (non-blocking)

1. First use of CONCURRENTLY - This is the first migration in the codebase using CREATE INDEX CONCURRENTLY with refinery:no-transaction. The approach is correct, but worth noting for reviewers.

2. Test coverage - The new test test_organization_name_reuse_after_deletion (e2e_duplicate_names.rs:108-173) validates the fix, but relies on soft-delete working correctly via DELETE /v1/organizations/{id} endpoint.

---

Verdict: ✅ APPROVED

No critical issues found. This PR is safe to merge.

The migration correctly implements a partial unique index following established patterns (V0012), handles concurrent deployment scenarios safely, and includes comprehensive test coverage for the fix.