-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat: error clustering UI #20958
feat: error clustering UI #20958
Conversation
] | ||
def construct_response(df, team, user): | ||
viewed_session_ids = ( | ||
SessionRecordingViewed.objects.filter(team=team, user=user, session_id__in=df["session_id"].unique()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this list be potentially too long to be passed to Postgres?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think because we're scoping it to team and individual user we should be ok...
Could write a test to see how many session ids before we get an error but it's still not generally released so we should be ok
Size Change: 0 B Total Size: 821 kB ℹ️ View Unchanged
|
For the row's description when it's an error, since we know it's a stack trace and the first line is the "human readable" version of the error, instead of setting the whole stringified JSON, can we set just the first line? eg: |
@marandaneto great suggestion! I added the title parsing here: 2142c82. Only checking for the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one text suggestion but otherwise 🚢
] | ||
def construct_response(df, team, user): | ||
viewed_session_ids = ( | ||
SessionRecordingViewed.objects.filter(team=team, user=user, session_id__in=df["session_id"].unique()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think because we're scoping it to team and individual user we should be ok...
Could write a test to see how many session ids before we get an error but it's still not generally released so we should be ok
frontend/src/scenes/session-recordings/errors/SessionRecordingErrors.tsx
Outdated
Show resolved
Hide resolved
function parseTitle(error: string): string { | ||
try { | ||
const parsedError = JSON.parse(error) | ||
return parsedError.error || error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still just get the 1st line here since the error is always a stack trace.
ah gotcha, I thought that was the general structure for all errors. |
…Errors.tsx Co-authored-by: Paul D'Ambra <[email protected]>
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
should we get this in? |
@pauldambra yep, E2E Cypress tests have failed a couple of times now. Rerunning them but might have to do so locally if they don't work this time |
Ah, they've passed now but it was the accidentally required depot steps failing, sorry! |
Problem
The first UI needed some work
Changes
Does this work well for both Cloud and self-hosted?
👍
How did you test this code?