You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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)
Rather than a tooltip of shame and disappointment, we should simply not show this button if we don't have a session id:
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)
The text was updated successfully, but these errors were encountered:
Figured I'd collect them somewhere other than Davids DM's
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)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.The text was updated successfully, but these errors were encountered: