Bug: `setDefaultCard` transaction allows zero-default state under concurrent requests

[Srejoye]

apps/backend/src/services/cardService.ts — setDefaultCard() runs:

await app.prisma.$transaction(async (tx) => {
  await tx.card.updateMany({ where: { userId }, data: { isDefault: false } });
  await tx.card.update({ where: { id }, data: { isDefault: true } });
});

This transaction does not specify an isolation level (unlike createCard, which explicitly uses Serializable). Under the Postgres default Read Committed isolation, two concurrent setDefaultCard calls for the same user (e.g. double-tap on "set as default" in the UI, or two browser tabs) can interleave such that:

• Tx1 clears all isDefault flags for the user.
• Tx2 clears all isDefault flags for the user.
• Tx1 sets card A as default.
• Tx2 sets card B as default.

Final state: both A and B are momentarily isDefault: true only if both updates land — but more commonly the lost-update pattern produces a window where the updateMany from Tx2 (clear all) commits after Tx1's update (set A default), wiping out A's default flag without setting B's, depending on commit ordering, leaving zero cards marked default for that user.

This directly desyncs from createCard's invariant (isDefault: cardCount === 0 — exactly one default on creation) and deleteCard's invariant (always promotes a new default when the default card is deleted). Any UI/profile-rendering code that assumes exactly one isDefault: true card exists per user will silently show no default card or crash on .find(c => c.isDefault) returning undefined.

Affected: apps/backend/src/services/cardService.ts (setDefaultCard), contrast with createCard and deleteCard in the same file which maintain the "exactly one default" invariant carefully.

[github-actions]

Hi @Srejoye,

Thanks for opening this issue.

Please reply with one of the following areas so the issue can be routed to the appropriate team member:

- /backend
- /web
- /mobile
- /devops

Once an area is selected, the corresponding label will be added automatically.

[Srejoye]

/backend

[Srejoye]

Understanding: createCard and deleteCard both carefully preserve the "exactly one isDefault card per user" invariant (the former using a Serializable transaction with retry-on-P2034, the latter by re-promoting the oldest remaining card). setDefaultCard uses the same two-step clear-then-set pattern but without Serializable isolation, so it's the weak link — concurrent calls can leave 0 (or, on some interleavings, transiently >1) cards with isDefault: true.

Affected files: apps/backend/src/services/cardService.ts (setDefaultCard), and any consumer in apps/backend/src/routes/cards.ts exposing this.

Proposed fix approach: Add { isolationLevel: 'Serializable' } to the $transaction call in setDefaultCard, mirroring createCard's retry-on-P2034 loop (3 attempts). Alternatively, do the flip in a single conditional updateMany (set isDefault: (id === targetId)) to reduce write count and serialization conflicts.

Test considerations: Unit/integration test firing two concurrent setDefaultCard calls for different cards belonging to the same user, then asserting via listCards that exactly one card has isDefault: true afterward (run multiple iterations to catch the race probabilistically, or use a deliberate setTimeout/Promise.all interleave with mocked Prisma transaction ordering).

Requesting this issue be assigned to me under GSSoC'26.

[github-actions]

The issue has been classified as backend.

@Harxhit, please review and triage this issue when available.

The backend label has been applied and the issue has been routed accordingly.

[Harxhit]

@Srejoye I have assigned this issue to you.