[comp] Production Deploy #1963
[comp] Production Deploy #1963
Conversation
…ble unicode characters (#1962) Co-authored-by: Tofik Hasanov <[email protected]>
PR SummaryIntroduces assistant chat session persistence and overhauls vendor risk assessment data flow with UI updates.
Written by Cursor Bugbot for commit d786d79. This will update automatically on new commits. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
|
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 <[email protected]>
![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.
Additional Locations (1)
* feat(api): add assistant chat history management endpoints * refactor(api): extract user context validation into a separate method --------- Co-authored-by: Tofik Hasanov <[email protected]>
| data: { | ||
| status: VendorStatus.in_progress, | ||
| }, | ||
| }); |
There was a problem hiding this comment.
Vendor status stuck in generating state on task failure
The vendor status is set to VendorStatus.in_progress early in the task execution, but is only set to assessed on successful completion. If the task fails after setting in_progress (e.g., Firecrawl research fails, network errors) and exhausts all retry attempts, there's no failure handler to reset the status. The vendor remains permanently stuck in in_progress state, displaying "generating" in the UI with no automatic recovery mechanism.
Additional Locations (1)
| <div className="flex-1 space-y-6 min-w-0"> | ||
| {isGeneratedTask ? ( | ||
| <GeneratedTaskItemMainContent taskItem={taskItem} /> | ||
| ) : ( |
There was a problem hiding this comment.
Old structured risk assessment tasks will display raw JSON
The specialized renderer for existing "Risk Assessment" tasks with structured JSON descriptions (containing kind: "vendorRiskAssessmentV1") was removed. These tasks are now passed to CustomTaskItemMainContent, which uses parseDescription to process the description. Since the structured JSON has neither type: "doc" nor is an array, parseDescription wraps the entire JSON string as plain text via wrapPlainText(desc). Users with existing risk assessment tasks will see raw JSON displayed instead of the formatted risk assessment view with certifications, timeline, and security assessment details.
Additional Locations (1)
|
🎉 This PR is included in version 1.72.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.