A failed recipe update can wipe out the recipe's data anyway

This is the worst class of bug an API can ship: the request the user made failed (they got an error back, or at least not a success), and yet their data is gone anyway. A recipe author tries to update a recipe, makes a mistake in the payload that the database rejects, gets back a failure -- and when they go look at the recipe afterward, it now has zero ingredients and zero steps. There is no error message telling them this happened, no undo, and nothing in the API's response hints at it -- the failed request looks like it just... failed, while quietly deleting everything. For anything resembling production data, this is the kind of bug that turns into an incident: support tickets from users insisting "I didn't touch it, it just disappeared," with no audit trail pointing back to the failed PUT that actually did it.

PUT /recipes/:id deletes the recipe's existing ingredients and steps before attempting to recreate them, and those deletes are not part of the same transaction as the recreate. If the recreate step then fails for any reason (e.g. the request accidentally contains two steps with the same stepNumber, which violates the @@unique([recipeId, stepNumber]) constraint in prisma/schema.prisma), the recreate rolls back -- but the deletes, having already committed as separate statements, do not roll back with it. The recipe survives (it was never itself deleted), but it's left with none of its original ingredients or steps.

curl -X POST http://localhost:3001/recipes -H "Content-Type: application/json" -d '{ "title": "Chicken Stir Fry", "cookingTimeMinutes": 20, "servings": 4, "ingredients": [{"name": "Chicken breast", "quantity": 500, "unit": "g"}], "steps": [ {"stepNumber": 1, "instruction": "Slice the chicken."}, {"stepNumber": 2, "instruction": "Cook it."} ] }'

-> 201, note "id"

curl -X PUT http://localhost:3001/recipes/<id> -H "Content-Type: application/json" -d '{ "title": "Chicken Stir Fry", "cookingTimeMinutes": 20, "servings": 4, "ingredients": [{"name": "Chicken breast", "quantity": 500, "unit": "g"}], "steps": [ {"stepNumber": 1, "instruction": "First step."}, {"stepNumber": 1, "instruction": "Duplicate step number -- the DB rejects this."} ] }'

-> 500 (the request fails, as it should)

This is a transaction-boundary bug, not a logic bug -- every individual statement here is written correctly in isolation, and the mistake only shows up when you trace which operations are (and aren't) inside the prisma.$transaction(...) block. The delete calls use the plain prisma client; the recreate uses the tx client Prisma hands to the transaction callback. Those are two different execution contexts, and Postgres commits each one independently -- the deletes are permanent the instant they run, regardless of what happens next. This is exactly the kind of defect that's invisible from a single successful request (delete-then-recreate looks identical to a rollback-safe version when nothing fails) and only shows itself when the second half of the operation fails -- which is precisely why a dedicated test for the failure path (not just the happy path) is what catches it.

Look at how POST /recipes's nested-create handler in this same file gets true all-or-nothing behavior "for free" (per the comment above it) by keeping every write inside a single Prisma call. Now look at where the prisma.$transaction(...) boundary actually starts and ends in the PUT handler relative to the two deleteMany calls -- and at which client object (prisma vs the tx argument) each of the four database calls in this handler is issued through.