Feedback and Diagnostics

The Support flow is how a user reports a problem or idea from inside the app, and how the app itself tells the RaceTagger team something went wrong without the user doing anything. There are three parts: (1) the Support button (bottom-right floating action button, "Report a bug, request a feature, or share your feedback — we're listening!") opens a modal that always attaches full diagnostics and creates a GitHub issue; (2) Automatic Error Reporting silently reports critical failures and hard crashes as they happen, deduplicated and turned into GitHub issues without any user action; (3) an occasional satisfaction check-in after a large analysis, whose negative branch routes into the same Support pipeline. None of this requires the user to find or attach a log file themselves — diagnostics are collected and uploaded automatically as part of both flows.

How to use it

Limits and known behaviour

• The GitHub issue link is not shown to the user. submit-support-feedback returns issueNumber/issueUrl on success, but feedback-modal.js only shows a generic "Report Sent" message — if a customer wants to reference their issue, ask support/dev to look it up, don't expect the app to have told them the number.
• "Automatic Error Reporting" resets to ON every app restart. The toggle (set-telemetry-enabled) only flips an in-memory flag (ErrorTelemetryService.enabled, default true) — nothing is persisted to disk. A user who disabled it will have it re-enabled the next time they launch the app. (Also documented on the settings-and-preferences page.)
• Full diagnostics are always attached to a Support submission — includeDiagnostics is hardcoded true in feedback-modal.js; there is no way to send feedback without them from the UI.
• Diagnostic upload happens before GitHub issue creation but is non-blocking: if the Supabase Storage upload fails, the issue is still created, just without a diagnostic report link.
• Automatic error telemetry is rate-limited: max 5 reports per execution, 20 per day per user, and deduplicated by a fingerprint (error type + normalized message + phase + platform) — a repeat of the same error within 5 minutes is silently skipped, and a repeat later just adds a comment to the existing GitHub issue rather than opening a new one.
• Telemetry reports queued before login, or queued in the ~30s before the periodic flush when the app crashes, are not lost: they are written to a telemetry-pending.json file in the userData folder and retried on the next launch (capped at 50 items, 7 days, 5 attempts).
• Native crash minidumps (Crashpad) are written to disk only, never uploaded — only the fact that a crash happened (plus sanitized log context) is sent through the same telemetry pipeline as a handled error.
• An abnormal exit (OOM kill, force-quit, power loss — no minidump) is detected from a missing [SESSION END] marker in the previous session's log and reported as a lower-severity abnormal_exit, capped at 3 reports per launch to avoid flooding after a crash loop.
• The satisfaction check-in and the referral milestone nudges are admin-controlled server-side (enable/disable, photo threshold, reward shown, milestones) via the satisfaction-survey Edge Function — nothing in the desktop app itself gates when they appear, so behaviour can change without an app update.
• Both flows are online-required: survey:get-eligibility and submit-support-feedback need an authenticated session; if there is no network or the user is logged out, the survey simply never appears and Support submission fails with an explicit error.