Problem
control-plane/src/neon-database-driver.ts's branchNameFor sanitizes a tenant/product-derived name, then unconditionally .slice(0, 63)s the result (Neon's branch-name length limit) with no check that the truncated result is still unique.
Two distinct tenant names sharing the same first ~50 characters (after the tenant-${product}- prefix and sanitization) would truncate to the identical Neon branch name. provisionNeonDatabase's findBranchByName would then find the other tenant's already-existing branch and hand back its connection/role/password to the new tenant — a cross-tenant data-isolation bug. No test in test/neon-database-driver.test.ts exercises the truncation path.
This needs real Neon length/uniqueness semantics validated against a live account before a fix (e.g. appending a short hash of the untruncated name) is safe to merge — the exact real-infra dependency this issue's boundaries below call out.
Area
control-plane/src/neon-database-driver.ts (branchNameFor).
Proposal
Add a collision-resistant suffix (e.g. a short hash of the pre-truncation name) when the sanitized name would otherwise be truncated, so two long, prefix-similar tenant names can never collide on the same Neon branch name. Validate the exact scheme against Neon's real branch-naming constraints before merging.
Deliverables
Resources
control-plane/src/neon-database-driver.ts (branchNameFor, provisionNeonDatabase/findBranchByName)test/neon-database-driver.test.ts (where the missing truncation-collision test belongs)
Boundaries
Scoped to the branch-naming collision issue only — not a broader audit of the Neon driver.
maintainer-only — this touches the real tenant-database provisioning driver and needs validation against live Neon API semantics before a fix is safe to merge; a naive contributor patch risks getting the truncation/hashing scheme subtly wrong against real infra constraints.
Problem
control-plane/src/neon-database-driver.ts'sbranchNameForsanitizes a tenant/product-derived name, then unconditionally.slice(0, 63)s the result (Neon's branch-name length limit) with no check that the truncated result is still unique.Two distinct tenant names sharing the same first ~50 characters (after the
tenant-${product}-prefix and sanitization) would truncate to the identical Neon branch name.provisionNeonDatabase'sfindBranchByNamewould then find the other tenant's already-existing branch and hand back its connection/role/password to the new tenant — a cross-tenant data-isolation bug. No test intest/neon-database-driver.test.tsexercises the truncation path.This needs real Neon length/uniqueness semantics validated against a live account before a fix (e.g. appending a short hash of the untruncated name) is safe to merge — the exact real-infra dependency this issue's boundaries below call out.
Area
control-plane/src/neon-database-driver.ts(branchNameFor).Proposal
Add a collision-resistant suffix (e.g. a short hash of the pre-truncation name) when the sanitized name would otherwise be truncated, so two long, prefix-similar tenant names can never collide on the same Neon branch name. Validate the exact scheme against Neon's real branch-naming constraints before merging.
Deliverables
branchNameForproduces a collision-resistant result for names that would otherwise truncate identically.Resources
control-plane/src/neon-database-driver.ts(branchNameFor,provisionNeonDatabase/findBranchByName)test/neon-database-driver.test.ts(where the missing truncation-collision test belongs)Boundaries
Scoped to the branch-naming collision issue only — not a broader audit of the Neon driver.
maintainer-only — this touches the real tenant-database provisioning driver and needs validation against live Neon API semantics before a fix is safe to merge; a naive contributor patch risks getting the truncation/hashing scheme subtly wrong against real infra constraints.