fix(apollo): ApiKey deletes set deleted=true so soft-delete middleware filters them

@kaavee315draftchecks n/achecks…fix/apikey-soft-delete → master8 files · +395 −3updated 5d ago

▸Description

Description

ApiKey rows are soft-deleted by setting a timestamp, but the prisma-soft-delete-middleware (configured in packages/db/src/client.ts with ApiKey: true) filters ApiKey reads on the boolean deleted column — NOT on deletedAt. Several delete paths set only deletedAt: new Date() and never set deleted = true, so those soft-deleted rows stayed visible to any read that relied on the middleware filter.

This PR makes every ApiKey soft-delete set BOTH deleted: true and deletedAt, and backfills the pre-existing inconsistent rows.

Code changes (all ApiKey-model soft-delete paths now set deleted: true):

apps/apollo/src/lib/apiKeys/dbUtils/index.ts — deleteAPIKey and deleteAllApiKeysForProject.
apps/apollo/src/pages/api/internal-dashboard/team-members/remove/[id].ts — the team-member-removal ApiKey sweep (added during review; it set only deletedAt).
apps/apollo/src/lib/consumer/provision.ts — the consumer-key re-provision soft-delete (added during review; it set only deletedAt).

apps/apollo/src/pages/api/v3.1/api_key_revocation.ts already set both fields and is unchanged. The userApiKey/orgApiKeys paths are not affected: those models are not registered in the soft-delete middleware, so their deletedAt-only deletes are correct.

Liquibase migration v105_backfill_api_key_deleted_flag (registered in changelog-root.json after v104):

Pure data backfill (no schema change — both columns already exist).
Sets deleted = true for every public.project_api_keys row where deletedAt IS NOT NULL AND deleted = false.
Batched (5000/batch, autocommit per batch) so it never holds row locks over the whole table, and idempotent (re-running only touches rows still in the inconsistent state). Mirrors the sibling v103 backfill.
down.ts resets deleted = false for the backfilled rows (best-effort; it also touches rows set by the fixed code paths — documented in the file).

The five manual deletedAt: null read guards in dbUtils/index.ts are INTENTIONALLY KEPT for now as defense-in-depth. Removing them is a deliberate follow-up that MUST come AFTER this migration has run in staging/production and the deleted column is confirmed consistent with deletedAt.

Tests: apps/apollo/src/lib/apiKeys/dbUtils/deleteApiKey.unit.test.ts — 6 cases covering both dbUtils delete paths, asserting the data payload sets deleted: true + deletedAt, the where scoping, and the Err path.

How did I test this PR

node_modules is not installed in this worktree, so local typecheck/tests could not be run. Relying on CI check-types and run-vitest-tests.
Verified statically that ApiKey is registered in the soft-delete middleware (packages/db/src/client.ts) and that the library filters on the boolean deleted field, confirming the root cause.
Grepped every prisma.apiKey/tx.apiKey update/updateMany/delete call site in apps/apollo/src; confirmed all ApiKey-model soft-delete paths now set deleted: true, and that userApiKey/orgApiKeys are not middleware-managed.
Confirmed the deleted field is a valid ApiKeyUpdateManyMutationInput member (the schema declares deleted Boolean, already written by the dbUtils paths).
Reviewed v105 against the sibling v103/v104 migrations: changelog shape, root-changelog ordering/format, and up/down batching all match.

Before merge: v105 must be run against staging (and reviewed) per packages/db/docs/DB_MIGRATIONS_GUIDE.md. The guard-removal cleanup is a separate follow-up PR after the backfill is confirmed.

🤖 Generated with Claude Code

loading diff…