-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
refactor: improve error handling during ClickHouse query type mismatch while filtering session replays #24300
refactor: improve error handling during ClickHouse query type mismatch while filtering session replays #24300
Conversation
Looks good to me but going to tag the Product Analytics team for a review because they will be much more familiar with the HogQL code |
…he SessionRecordingViewSet level
5442816
to
f19d4f0
Compare
Hey @daibhin @webjunkie, thanks for your insightful reviews! I’ve pushed the required changes now. Please take a look when you get a chance |
posthog/errors.py
Outdated
53: ErrorCodeMeta("TYPE_MISMATCH", user_safe=True), | ||
53: ErrorCodeMeta( | ||
"TYPE_MISMATCH", | ||
user_safe="One or more property values in your filters are in an incorrect format." |
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.
This needs to stay as boolean.
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.
Lines 36 to 39 in bb997bc
user_safe: bool | str = False | |
"""Whether this error code is safe to show to the user and couldn't be caught at HogQL level. | |
If a string is set, it will be used as the error message instead of the ClickHouse one. | |
""" |
Lines 303 to 306 in bb997bc
241: ErrorCodeMeta( | |
"MEMORY_LIMIT_EXCEEDED", | |
user_safe="Query exceeds memory limits. Try reducing its scope by changing the time range.", | |
), |
@webjunkie I observed that user_safe
is being assigned a string value in a few other scenarios, which made me think this might be the ideal way to handle it. I'll go ahead and change user_safe
to a boolean as suggested
Can you please let me know the best way to provide a more descriptive error message in that case?
Should I handle this by overriding the message in the SessionRecordingViewSet where the ValidationError is raised, or is there another approach you'd recommend?
TIA
CC: @daibhin
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 we will want to capture the error on the frontend and display it there. If you look at the frontend/src/scenes/session-recordings/playlist/sessionRecordingsPlaylistLogic.ts
file you should be able to add a new listener for loadSessionRecordingsFailure
and maybe call lemonToast.error
with the user safe string
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.
Got it, thanks! Will give it a try
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 we will want to capture the error on the frontend and display it there. If you look at the
frontend/src/scenes/session-recordings/playlist/sessionRecordingsPlaylistLogic.ts
file you should be able to add a new listener forloadSessionRecordingsFailure
and maybe calllemonToast.error
with the user safe string
Have pushed this change now via commit: b9e1257
… instead of sending it from the server
a3338ee
to
b9e1257
Compare
try: | ||
return list_recordings_response(filter, request, self.get_serializer_context()) | ||
except (ExposedHogQLError, ExposedCHQueryError) as e: | ||
raise ValidationError(str(e), getattr(e, "code_name", None)) |
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 kept the section that raises ValidationError
because I believe ExposedHogQLError
and ExposedCHQueryError
are client-side errors. Therefore, a 4xx HTTP status code, particularly 400 (bad request), seems more fitting than the 500 (internal server error) status code that was originally being used.
Please let me know if this assumption is incorrect and if I should adjust or remove this implementation
try { | ||
response = await api.recordings.list(params) | ||
} catch (error: any) { | ||
captureException(error) | ||
actions.loadSessionRecordingsFailure(error.message, error) | ||
|
||
return { | ||
has_next: false, | ||
results: [], | ||
} | ||
} |
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.
If the exception isn't handled in this code section, it will be processed by the loadersPlugin
in initKea.ts
. This will trigger the onFailure
function, which already includes error handling with lemonToast.error
, resulting in a duplicate error toast.
For reference, here’s the relevant code:
posthog/frontend/src/initKea.ts
Lines 102 to 104 in 145cacf
if (errorMessage) { | |
lemonToast.error(`${identifierToHuman(actionKey)} failed: ${errorMessage}`) | |
} |
I’ve added exception handling above to prevent the duplication of error toasts.
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
if (errorObject?.data?.type === 'validation_error' && errorObject?.data?.code === 'type_mismatch') { | ||
lemonToast.error( | ||
'One or more property values in your filters are in an incorrect format.' + | ||
' Please check and adjust them to match the required data types.' |
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.
the perfect thing here would be for the toast to link to the data management properties page... iirc we can set a button on the toast so the person has an onward journey
(even better if it's to the specific property)
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.
Looks good to me! Just some PR checks are red – can you resolve this @namit-chandwani?
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant. |
Pull request was closed
Linked Issues
Problem
Changes
Backend:
posthog/errors.py
:CLICKHOUSE_SPECIFIC_ERROR_LOOKUP
dictionary to include theTYPE_MISMATCH
error with a descriptive message guiding users to correct the data types used in their filters.posthog/session_recordings/session_recording_api.py
:list
method withinSessionRecordingViewSet
to handleExposedCHQueryError
andExposedHogQLError
exceptions by raising aValidationError
with an appropriate error message and status code (400: Bad Request
).Frontend:
These changes improve the robustness of error handling for ClickHouse queries, offering users clearer and more actionable error messages, especially in cases where there is a type mismatch in filter parameters during session recording queries.
Does this work well for both Cloud and self-hosted?
How did you test this code?
Manual Testing:
Screen Recording of Testing:
PostHog.CH.Error.Handling.mov
Type of change:
Checklist:
Follow-up tasks (if any):
Additional Comments