Crash reports and error recovery: the opt-in and the fallback screen

What it does

Two mechanisms work together. The first is a React error boundary placed around each protected zone of the application. If a component in that zone throws while rendering, React would otherwise unmount the whole tree and leave a black window; the boundary catches it, logs the error to the console with the component stack, and renders a card in place of the zone. The rest of the application keeps running: the data feed and the broker connection are untouched.

The second is the crash reporter. When the boundary catches a render error, or when a global handler sees an unhandled promise rejection or an uncaught error outside React, a report is assembled and posted, but only if you consented. The setting is stored locally under a single key; absent means no consent. Sending is fire-and-forget: the error screen is never delayed by the request, and a failed send fails without any popup.

Settings

What the report contains

The payload has six fields: kind (panic for the Rust side, render for a React render error, unhandled for a rejected promise or uncaught error), message, stack, appVersion, platform and the timestamp. The message is cut at 1 000 characters and the stack at 4 000, keeping the top frames that carry the information.

Before being placed in the payload, message and stack pass through a scrubber that masks AI API keys, Bearer and Basic tokens, Windows and Unix user paths (bounded at the path separator so a two-word Windows account name does not leak its second half), email addresses and sensitive key/value pairs such as password, token, api_key, user_id, unique_user_id, login or account. A test pins these patterns with the real forms they take in the application's error messages. Broker credentials, account name, positions, P&L, traded symbols and the AI key are never part of the report.

A throttle keeps one report per distinct signature (kind plus the first 200 characters of the scrubbed message) and at most five distinct signatures per session, so a rendering loop that throws every frame does not produce hundreds of requests.

How to use it

• If a screen shows This screen stopped, click Reload first. If it happens again, click Copy the details and paste the text into a report from the Report a problem screen, which also attaches the last error lines automatically.
• Turn Crash reports on in the Account page if you want render and unhandled errors to reach the developers without any action on your side. The label next to the checkbox states exactly what is and is not sent.
• The Report a problem screen is a separate, voluntary channel with its own visible failure messages; the crash reporter is automatic and silent by design.

Limits and pitfalls

• The boundary covers render errors in its zone. Errors in event callbacks, timers and dynamic imports are caught by the global handlers, which report but do not show the card.
• The consent is a single local-storage key on this machine; a fresh profile, a cleared storage or a storage the app cannot read all mean no consent, so nothing is sent.
• The report is sent to the canonical domain with a 5-second timeout; if the machine is offline the report is dropped, not queued.