Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error ui notes #26418

Open
17 tasks
oliverb123 opened this issue Nov 26, 2024 · 0 comments
Open
17 tasks

error ui notes #26418

oliverb123 opened this issue Nov 26, 2024 · 0 comments

Comments

@oliverb123
Copy link
Contributor

Figured I'd collect them somewhere other than Davids DM's

  • If the stack trace collapsible is in "in-app only" mode, and the top trace is open, switching to "all frames" mode auto-opens the top frame, rather than persisting the currently open frames across the mode-switch
  • The symbol set management page's first sub-heading talks about "source maps", but the heading talks about "symbol sets". We should talk only about "symbol sets" at the top level, and the upload modal should let users choose the language, and configure itself based on that choice (with JS being the only language available right now)
  • We need a second heading for the found symbol sets, explaining what they are
  • We should include a timestamp on the found symbol sets (and the failed ones), so users can self-debug if we're using an invalid copy or something
  • The symbol set collapsible does not show a "loading" spinner, but just expands a tiny bit, and then stays in this state until the frames load - looks like this:
image
  • Symbol sets with no associated frames look identical to the picture above of sets in their "loading" state
  • The symbol sets table should be fuzzy-searchable by reference
    • maybe even searchable by contents of associated frames?
    • MAYBE even searchable by contained symbols, but that's a harder one
  • We should allow people to delete error'd symbol sets, as well as found ones, to force us to re-try fetching
  • The symbol-sets page should be another tab on the error-tracking page, rather than a "configuration" page tucked into the top right corner - how many configuration pages does posthog have? I count 3 different gear icons in this image alone:
image
  • The error tracking detailed issue page looks like mostly a copy of the replay ui, we should maybe reconsider? Longer term thing
  • In that "issue detail" view, in cases where we fail to handle an exception event, this error ui makes it look like the error being display /is/ the exception data. Something like "Whoops, posthog couldn't process this: " would help, maybe with a cute hedgehog. It also shouldn't have that "stack trace" region (that's where the cute hedgehog should go)
image
  • Rather than a tooltip of shame and disappointment, we should simply not show this button if we don't have a session id:
image
  • When showing an exception event, for frames we failed to find a symbol set for (but that have a source), we should add a little button on the right deep-linking you to the symbol set management page with that symbol set highlighted (or better, have a dedicated detail page for individual symbol sets that we can deep-link to)
  • When displaying exception events, we should not show the properties tab - I have yet to find a single exception where it doesn't cause my whole browser to stutter for a few seconds before opening, and that sucks so hard I'd rather not show it at all until someone beats down our door for it.
  • We should handle the stacks of recursive functions more elegantly (this might be a client-side thing, or in cymbal, or ui - I can think of things we can do everywhere here, but UI is the place that would preserve the most information)
image
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

No branches or pull requests

1 participant