fix(backend): wrap card updates in a transaction to prevent data loss

[anshul23102]

Summary

When PUT /api/cards/:id is called with a new linkIds array, the handler ran two database writes sequentially outside a transaction: first deleteMany to remove existing card links, then createMany to insert the new ones. If the createMany failed (constraint violation, network error, etc.), the deletion was already committed and the card was left with zero links. This PR wraps both operations in a Prisma $transaction so either both succeed or neither does.

Closes #216

---

Type of Change

• Bug fix
• New feature
• Refactor (no functional change)
• UI / Design change
• Tests only
• Documentation
• Infrastructure / DevOps
• Security

---

What Changed

apps/backend/src/routes/cards.ts

Before (two independent writes, no transaction):

await app.prisma.cardLink.deleteMany({ where: { cardId: id } });
await app.prisma.cardLink.createMany({ data: newLinks });

After (atomic transaction):

await app.prisma.$transaction(async (tx) => {
  await tx.cardLink.deleteMany({ where: { cardId: id } });
  await tx.cardLink.createMany({ data: newLinks });
});

Additional changes:

• Added an ownership check before any write: fetches all supplied linkIds that belong to the authenticated user and rejects with 403 if the count does not match, preventing users from adding other users' links to their card
• Wrapped PUT /:id/default in a transaction so the existing default is cleared and the new default is set atomically

apps/backend/src/__tests__/cards.test.ts

• Updated test mocks to include $transaction support
• Added tests for the 403 ownership check path
• Added tests verifying the transaction rolls back on failure

---

How to Test

1. Create a card with two links.
2. PUT /api/cards/:id with a linkIds array containing a valid link ID — confirm the card now has exactly that link.
3. Simulate a createMany failure (mock it to throw) — confirm the card links are unchanged after the failed request.
4. PUT /api/cards/:id with a linkIds array containing a link ID that belongs to a different user — confirm the response is 403 and no writes occur.

---

Checklist

• My code follows the project's coding style (pnpm -r run lint passes).
• TypeScript compiles without errors (pnpm -r run typecheck).
• I have added or updated tests for the changes I made.
• All tests pass locally (pnpm -r run test).
• I have updated documentation where necessary.
• No new console.log or debug statements left in the code.
• Breaking changes are documented in this PR description.

---

Screenshots / Recordings

N/A (backend-only change, no UI impact)

---

Additional Context

Without the transaction, a network error or constraint violation between the two writes left the card in a permanently link-less state with no recovery path other than a direct database edit. The fix applies the same $transaction pattern already used elsewhere in the codebase for atomic multi-step writes.

[Prince2301p]

Hi,
I would like to work on resolving this issue. Please assign it to me. I’m a participant in GSSoC 2026 and would be happy to contribute.
Looking forward to collaborating with you.

[anshul23102]

Hi @Dev-Card team, just following up on this one. The issue it addresses is a silent data loss scenario: if any step in the card link update fails midway, partial writes get committed and the card ends up in an inconsistent state with no way to know which links were saved and which were not. Wrapping the whole operation in a Prisma transaction ensures it either fully succeeds or fully rolls back. All existing tests pass. Let me know if you would like any changes.

[anshul23102]

Hi @PrashantkumarKhatri! The Vercel check is showing 'Authorization required to deploy' on this one too - could you authorize the preview deployment when you get a chance? Ready for review whenever you are. Thanks!

[anshul23102]

Hi @asyncasanas, could you please add the appropriate labels to this PR when you get a chance? It would really help with tracking the contribution. Thank you!

[anshul23102]

Hi @Muneerali199, a friendly reminder on this PR. It has been about 4 days and it is conflict-free with no CI issues. Happy to address any feedback or make adjustments if needed. Thank you!

[anshul23102]

(Correction to previous comment: tagging the right reviewer) Hi @ShantKhatri and @Prince2301p, a kind reminder on this PR. It has been about 4 days and the branch is conflict-free with no CI issues. Please let me know if you need any revisions. Thank you!

[ShantKhatri]

Hi @anshul23102 , Please add proper PR description.

[anshul23102]

Hi @ShantKhatri, thanks for the feedback. I have updated the PR description with a more detailed breakdown including before/after code snippets showing the exact change, the reasoning for each guard added, and updated test coverage notes. Please let me know if there is anything else you would like added or changed.

[anshul23102]

Closing this PR as the underlying fix has already been incorporated into upstream main via PR #183 (which added $transaction to the card update path) and PR #327 (which refined the types). The only remaining change in this branch is a rewrite of cards.test.ts that reduces coverage from 440 lines (26 test cases) to 152 lines (4 test cases). Merging this would regress the existing test suite, so the right call is to close the PR. The issue is effectively resolved on main.