bluerobotics / bluerobotics/cockpit
Renderer errors that kill a widget never reach the syslog
- Dominant language
- TypeScript
- Stars
- 198
- Forks
- 63
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 57
Description
## Problem
When an unhandled error takes a widget down, the syslog records that it happened but never what it was. A user-submitted log showed the map and compass HUD both dying at startup, and this is everything it contained:
```
[Vue warn]: Unhandled error during execution of watcher callback at
[Vue warn]: Unhandled error during execution of setup function at
[Vue warn]: Unhandled error during execution of component update at
```
No message, no stack, no file. The real error turned out to be `TypeError: Cannot read properties of undefined (reading 'forEach')` at `src/libs/poi/poi-data-lake.ts:82`, thrown from the watcher in `src/composables/usePointsOfInterest.ts`. None of that is recoverable from the log.
## Why
- Vue's `logError` emits the `[Vue warn]` line and then rethrows, so the error escapes as an uncaught error rather than going through `console.error`.
- `src/libs/system-logging.ts` only patches `window.console[level]` (line 283), so it captures nothing that does not pass through `console.*`.
- `src/libs/index-utils.js` does register `window.addEventListener('error')` and `'unhandledrejection'` handlers (lines 59 and 70), but they are gated on `isCapturing`, which is set to `false` as soon as the `cockpit-app-loaded` event fires (line 80). Everything after startup is dropped.
- There is no `app.config.errorHandler` or `warnHandler` registered anywhere in the codebase.
## Impact
Any user report of a widget that "just doesn't work" arrives with the shape of the crash but not the reason, so it has to be reproduced locally and bisected by hand. This is the main reason the POI crash above took a full investigation to localise rather than being readable straight off the log.
## Suggestion
Register an `app.config.errorHandler` that writes the error message, stack and component name through the logger that system-logging captures, and keep a permanent `window` error / `unhandledrejection` hook rather than one that stops at startup.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with src/libs/system-logging.ts around line 283 and src/libs/index-utils.js around lines 59-80, then inspect how the application is initialized since no app.config.errorHandler or warnHandler is registered. Done means renderer errors reach the captured logger with their message, stack, and component name, while window error and unhandledrejection reporting continues after cockpit-app-loaded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100