Scope codebase slug/ref uniqueness to projects with a Cosmos-safe migration #1521

Please do not report security vulnerabilities here. Follow SECURITY.md instead.
Redact secrets and sensitive data from examples, logs, and screenshots.

Summary

Codebase GUIDs and project associations already exist, but database-enforced uniqueness of human-readable codebase slugs and revision refs is not consistently project-local.

A legacy global unique slug or ref index can prevent one project from using a codebase slug/ref that is already reserved by an unrelated project. Conversely, deployments where legacy unique-index creation did not succeed may lack database protection against concurrent same-project duplicates. These are distinct states and must be established through read-only index inspection, not assumed.

Track this separately from the RBAC rollout: project membership authorization and project-scoped reference validation must remain enforced, while the codebase uniqueness/schema change is deferred as an explicit follow-up rather than a prerequisite for deploying RBAC.

Steps to reproduce

1. Benchmark task/scenario, agent/model, persona, and evaluation criteria: N/A; this affects API persistence and schema migration.
2. In a disposable test database with a legacy global unique index on codebases.slug, create a codebase with slug demo in project A.
3. Create a codebase with slug demo in project B. The projects and codebases have different GUIDs.
4. Verify that project B cannot retain the requested slug: the global constraint rejects the insert; depending on the API/store retry path, this may surface as an error or unsuccessful allocation. Exercise the analogous case for revision ref demo@r1 with a legacy global unique ref index.
5. Separately test concurrent same-project creation on a fixture without the required compound unique indexes. Application check-then-insert alone does not guarantee uniqueness.

These are proposed reproduction fixtures based on source inspection, not a claim that these steps were executed against shared dev. Actual shared-dev driver index metadata, records, and migration ledger have not been inspected.

Expected behavior

• Codebases and revisions retain stable, globally unique document GUIDs and immutable project associations.
• Project A and project B can both contain slug demo and revision ref demo@r1.
• Within a single project, the database rejects duplicate (projectId, slug) and (projectId, ref) values, including concurrent inserts.
• Soft-deleted codebases/revisions continue reserving their existing names within the project according to current behavior.
• Authorization and reference resolution remain project-scoped; GUID addressing does not bypass membership checks.
• Existing data, IDs, parent references, revision counters/latest pointers, request/run references, and archive URLs survive any schema transition.

Recommended fix

Introduce verified, unique, non-sparse, unfiltered compound indexes:

• codebases: { projectId: 1, slug: 1 }, proposed name uniq_project_codebase_slug.
• codebase-revisions: { projectId: 1, ref: 1 }, proposed name uniq_project_codebase_ref.

Inspect actual index definitions, partitioning, duplicates/malformed keys, and authentic migration history before choosing the upgrade path. Preserve the native Mongo path, but implement a verifier-first Cosmos-aware schema path rather than treating successful native Mongo tests as Cosmos evidence.

For Cosmos DB for MongoDB accounts using Continuous backup, define unique indexes at collection creation through the Cosmos CreateCollection extension. Existing collections cannot acquire them in place; existing unique constraints also must not be assumed removable. Prefer an explicitly approved offline copy into a separate database with canonical, pre-indexed collections, followed by full data/reference validation and coordinated cutover while retaining the source. Versioned replacement collections are an alternative only if every store, authorization/reference reader, migration, and direct consumer uses one consistent physical-name mapping. Cosmos Mongo 4.2 does not support renameCollection or copydb.

Fix initialization ordering as part of this work: migration 020 creates the codebase collections before migration 032 attempts the compound unique indexes. Merely creating an empty database or adding creation logic in 032 does not solve that ordering. Use a reviewed creation-time bootstrap/earliest-creation path and apply genuine pending migrations through the runner. Do not skip or fabricate ledger entries, drop mandatory constraints, reset existing data, or use application-only duplicate checks as the replacement guarantee.

Acceptance should cover native Mongo and isolated Continuous-backup Cosmos fixtures: same-project duplicate rejection under concurrency, cross-project slug/ref reuse, soft-delete reservations, verified index names/options/collation/partition compatibility, fresh initialization, existing-data upgrades, reruns, interrupted-copy/migration recovery, authentic ledger completion, and fail-closed cutover/rollback. After destination writes begin, rollback must not lose those writes or resurrect stale access state.

Actual behavior

At the investigated RBAC checkpoint, migration 020 attempts global unique slug/ref indexes and catches index-creation failures. Migration 032 attempts to create the project-local unique indexes on existing collections, verifies both, then attempts removal of legacy global unique indexes. The RBAC branch also lists 032 as required for API readiness.

On Continuous-backup Cosmos Mongo, that in-place creation strategy conflicts with documented platform restrictions. Thus the proposed uniqueness improvement is also an avoidable deployment dependency for RBAC until deliberately separated. No actual Cosmos migration failure or specific end-user error has been captured; the evidence is repository behavior and official platform documentation.

Environment and logs

• Source investigation checkpoint: 6db2ddcb4e4288d4aa160e7db28b01412f85b2ce, RBAC feature branch; not an assertion about current upstream main behavior.
• Relevant target platform: RU-based Azure Cosmos DB for MongoDB 4.2 with Continuous backup. No environment identifiers, credentials, or document contents are included.
• Relevant sources at that checkpoint: packages/db-migrations/src/migrations/020-create-codebase-indexes.ts, 032-scope-codebase-uniqueness.ts, required-migrations.ts, packages/shared/src/codebases/codebase-store.ts, codebase-revision-store.ts, and apps/api/src/auth/authorization.ts.
• Migration 029 (users) and 031 (project_memberships) provide existing creation-time Cosmos unique-index patterns; their mandatory authentication/membership uniqueness must not be weakened while deferring codebase uniqueness.
• Run/request IDs and runtime logs: N/A; research only, with no shared-dev migration execution.

Official references:

• Cosmos Mongo unique-index restrictions and pre-created-index import guidance
• Continuous-backup limitations, including unique-index immutability
• CreateCollection extension and creation-time indexes
• Mongo API 4.2 supported commands

This issue authorizes no cloud migration or destructive recovery. Operational execution, maintenance, destination capacity, and retention/cutover plans require separate approval.