"Failed to create VEX rule" Error Shown When Re-marking a Path as False Positive After Reopening

[juliankepka]

Summary
When a vulnerability is reopened after a path was previously marked as false positive via the dependency graph, clicking the path again triggers an error: "Failed to create VEX rule". This is misleading. The error occurs because a matching VEX rule already exists, but instead of reapplying it, the system fails silently with an error toast.

Current Behavior

• User marks a path as false positive via the dependency graph → VEX rule is created successfully.
• User reopens the vulnerability.
• User clicks the same path again to re-mark it as false positive.
• An error toast appears: "Failed to create VEX rule — failed to create VEX rule".
• The existing VEX rule is not reapplied.

Expected Behavior

• When the user clicks the path after reopening, the system detects that a matching VEX rule already exists.
• Instead of attempting to create a new rule and failing, the existing rule is reapplied.
• The UI feedback mirrors the first-time VEX flow exactly — same success toast, same state transition.
• No error is shown to the user.

Steps to Reproduce

1. Open a vulnerability.
2. In the dependency graph, click a path to mark it as false positive → VEX rule is created.
3. Reopen the vulnerability.
4. Click the same path in the dependency graph again.
5. Observe the error toast: "Failed to create VEX rule".

Root Cause (Hypothesis)
The backend attempts to create a new VEX rule without first checking whether one already exists for this path. The fix should include an upsert or reapply logic: if a matching rule exists, reapply it rather than rejecting the request.

Impact
Users are blocked from re-marking a path as false positive after reopening, with a confusing error message that implies something went wrong — even though the system state is valid.