[comp] Production Deploy #1963
[comp] Production Deploy #1963
Conversation
…ble unicode characters (#1962) Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
PR SummaryModernizes vendor risk assessments and related UX/backends.
Written by Cursor Bugbot for commit 26f86ee. This will update automatically on new commits. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Graphite Automations"Auto-assign PRs to Author" took an action on this PR • (01/02/26)1 reviewer was added to this PR based on Mariano Fuentes's automation. |
* feat(vendor): implement vendor risk assessment features and UI components * feat(vendor): enhance vendor risk assessment logic and domain extraction * refactor(vendor): remove distinct constraint for website in risk assessment * refactor(vendor): replace ShieldCheck icon with Shield icon in assessment view * refactor(vendor): remove backfill vendor risk assessment tasks and enhance task handling --------- Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| taskItemId: params.taskItemId, | ||
| }); | ||
| return await run(); | ||
| } |
There was a problem hiding this comment.
Advisory lock catches all errors causing double execution
The withAdvisoryLock function's error handling structure is flawed. The outer catch block catches errors from both lock acquisition AND the run() callback. If a database operation inside run() throws (e.g., constraint violation), the error is caught, the misleading message "Advisory lock unavailable" is logged, and run() executes a second time without lock protection. Since run() performs database updates and version increments, this causes double writes and incorrect version numbers (e.g., v1 → v3 instead of v1 → v2). The catch should only handle lock acquisition failures, not errors from the critical section.
| website: { | ||
| contains: domain, | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Domain substring matching causes wrong vendor data association
The GlobalVendors lookup uses website: { contains: domain } which performs substring matching and can match unrelated vendors. For example, searching for domain "a.com" would incorrectly match "nota.com", "data.com", or "mega.company". Similarly, "stripe.com" would match any website containing that substring. This causes risk assessment data to be incorrectly read from or written to the wrong vendor records. The pattern is used consistently across multiple files for both reads and writes.
Additional Locations (2)
| // Mark as ready for normal UX: clickable + full renderer | ||
| await db.taskItem.update({ | ||
| where: { id: taskItemId }, | ||
| const data = parseRiskAssessmentJson(description); |
There was a problem hiding this comment.
Research with null website saves empty data to GlobalVendors
The batch trigger includes vendors without valid websites (line 207: if (!domain) return true), passing vendorWebsite: null in the payload with withResearch: true. If the vendor's website is later updated before the task runs, the task passes the early-return checks (using current DB website) but research evaluates to null because payload.vendorWebsite is still null. The code then calls buildRiskAssessmentDescription with null research, creating empty data that gets saved to GlobalVendors, overwriting any existing risk assessment data for that website.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.