OUT-4027 | Fix 500 when deleting a task whose label row is missing (#… - #1398
Conversation
…1397) deleteLabel passed `id: currentLabel?.id` straight into label.delete, so when findFirst matched nothing Prisma got `{ id: undefined }` and threw PrismaClientValidationError, failing the whole delete transaction. Return early instead.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Greptile SummaryThe PR prevents task deletion from failing when its label mapping is already absent at lookup time and adds focused unit coverage.
Confidence Score: 4/5The PR should not merge until label cleanup is idempotent across the full operation, because concurrent cleanup can still abort task update or deletion transactions. The new guard fixes an initially absent row but retains a find-then-delete race in transaction-backed task flows, allowing a concurrent deletion to produce the same server failure. Files Needing Attention: src/app/api/label-mapping/label-mapping.service.ts Important Files Changed
Reviews (1): Last reviewed commit: "OUT-4027 | Fix 500 when deleting a task ..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (!currentLabel) return | ||
| await this.db.label.delete({ | ||
| where: { |
There was a problem hiding this comment.
If two task updates or deletions concurrently remove the same label mapping, both calls can pass findFirst, after which the second delete fails because the selected ID is gone, aborting its enclosing task transaction and returning the same class of 500 this change intends to prevent.
Knowledge Base Used: Workspace Settings & Configuration APIs
2 participants
…1397)
deleteLabel passed
id: currentLabel?.idstraight into label.delete, so when findFirst matched nothing Prisma got{ id: undefined }and threw PrismaClientValidationError, failing the whole delete transaction. Return early instead.Changes
Testing Criteria
Notes
Impact & Surface Area of Change