Skip to content

Release Feb 5th, 2026#2176

Merged
aarondr77 merged 42 commits intomainfrom
dev
Feb 5, 2026
Merged

Release Feb 5th, 2026#2176
aarondr77 merged 42 commits intomainfrom
dev

Conversation

@aarondr77
Copy link
Member

@aarondr77 aarondr77 commented Feb 5, 2026

Description

  • Quality of Life improvements for Chart Wizard
  • Remove Sonnet Support

@vercel
Copy link

vercel bot commented Feb 5, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
monorepo Ready Ready Preview, Comment Feb 5, 2026 3:26pm

Request Review

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

await downloadImage(found.dataUrl, format);
}
} else {
await downloadImage(found.dataUrl, format);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unhandled errors in chart export fallback path

Low Severity

The downloadImage call on line 38 (inside the catch block) and line 41 (in the else branch) can throw errors that aren't caught. If JPEG conversion fails via dataUrlToJpegBlob (e.g., canvas context unavailable, toBlob fails, or image loading error), the error propagates uncaught instead of being converted to { success: false, error: ... }. The caller handleExportChart in ChartWizardWidget.tsx expects a result object and won't show the error notification when the function throws, leaving users without feedback when export fails.

Fix in Cursor Fix in Web

await setRule(slugifiedName, formData.description, formData.isDefault);
if (editingRuleName && editingRuleName !== slugifiedName) {
await deleteRule(editingRuleName);
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rule rename can silently overwrite existing rules causing data loss

Medium Severity

When renaming a rule, the code calls setRule with the slugified name without checking if a rule with that name already exists. Because slugifyRuleName normalizes names (lowercasing, converting spaces to hyphens), different user inputs can collide. For example, if rules "rule-a" and "rule-b" exist and user edits "rule-a" changing its name to "Rule B" (slugifies to "rule-b"), the existing "rule-b" is silently overwritten, then deleteRule("rule-a") removes the old rule. Both rules' original content is lost.

Fix in Cursor Fix in Web

@aarondr77 aarondr77 merged commit 2e7bb82 into main Feb 5, 2026
105 of 115 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants