Repository navigation
feat(telemetry): report uncaught errors, and a screen to read them - #12
Merged
Merged
Conversation
The admin UI reported nothing when it broke, and nothing displayed the errors the API had started collecting — including the storefront's, which matter most commercially. Adds a global ErrorHandler, and an Errors screen showing grouped reports from both applications. The reporter carries the same guards as the storefront's, for the same reason: a component throwing during render calls the handler as fast as the browser can loop, so an identical error is reported at most three times per session, there is a hard per-session ceiling, and a failing endpoint is swallowed. Nothing assumes an Error shape, because anything can be thrown in JavaScript. It is a copy of the storefront's reporter rather than a shared package. Two Angular applications in separate repositories would need a published library to share about 150 lines, and the versioning cost outweighs the duplication — noted in the file so the next person knows a change belongs in both. The screen distinguishes three states that look alike if you are careless: nothing broken, nothing collected, and nothing loaded. Only the second names the setting to change, and the third says the load failed rather than showing an empty list. "Active in the last hour" is separated from the total, because a large count with nothing recent is a bug that has already been fixed. The page states plainly that it shows only what browsers managed to send: an error that breaks a page badly enough to stop the reporter never arrives, so a quiet list is no news rather than proof of no errors. Closes #11 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YY1ekLLeFLkAU2kvdQ8Ey4
PhilippTheServer
force-pushed
the
pl/error-reporting
branch
from
August 26, 2026 16:36
d3f7226 to
4d0b54f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #11 · completes S4 with OpenTaberna/fastapi#51 and OpenTaberna/frontend#5
Two halves: the admin UI now reports its own uncaught errors, and a new Errors screen
shows grouped reports from both applications — the storefront's included, because that
is where an administrator looks and where a fault costs a sale.
The screen distinguishes three states that look alike
FRONTEND_ERRORS_ENABLEDand how to turn it onAll three render an empty list if you are careless about it. Only the second is actionable
configuration, and only the third means something is wrong with the admin UI itself.
"Active in the last hour" is separate from the total. A large count with nothing recent
is a bug that has already been fixed, and it should not look like an emergency.
The reporter
Same guards as the storefront's, for the same reason — a component throwing during render
calls the handler as fast as the browser can loop:
Errorshape, since anything can be thrownIt is a copy, not a shared package. Two Angular apps in separate repositories would need
a published library to share ~150 lines, and the versioning cost outweighs the duplication.
That decision is written in the file so the next person knows a change belongs in both.
One real difference from the storefront's: the endpoint is absolute. The admin UI is served
by the Angular dev server while the API lives on another origin, so a relative path would
post to the wrong place.
Verification
Eight new tests on the screen, pinning: only still-happening errors count as active; a busy
recent error is dangerous while an old one is neutral; storefront errors are counted
separately; disabled is not confused with empty; empty is not reported as disabled; a failed
load is flagged rather than hidden; and one group expands at a time.
nav.model.spec.tsgoes from seven entries to eight — an intentional update to an existingassertion.