feat(errors): Allow searching for errors #25175
Conversation
|
Size Change: 0 B Total Size: 9.21 MB ℹ️ View Unchanged
|
📸 UI snapshots have been updated4 snapshot changes in total. 0 added, 4 modified, 0 deleted:
Triggered by this commit. |
| @@ -1523,6 +1523,7 @@ export interface ErrorTrackingQuery extends DataNode<ErrorTrackingQueryResponse> | |||
| assignee?: integer | null | |||
| filterGroup?: PropertyGroupFilter | |||
| filterTestAccounts?: boolean | |||
| searchQuery?: string | |||
There was a problem hiding this comment.
Agreed this makes sense as being separate to the filterGroup
| ast.CompareOperation( | ||
| op=ast.CompareOperationOp.Gt, |
There was a problem hiding this comment.
Not a concern for right now but maybe we could consider some degree of fuzzy matching in future
|
|
||
| self.assertEqual(len(results), 1) | ||
| self.assertEqual(results[0]["fingerprint"], ["DatabaseNotFound"]) | ||
| self.assertEqual(results[0]["occurrences"], 1) |
There was a problem hiding this comment.
I think the negative case is only implicitly tested e.g. what happens when the search query doesn't match - do we get 0 results?
| @@ -37,7 +37,9 @@ def to_query(self) -> ast.SelectQuery: | |||
|
|
|||
| def select(self): | |||
| exprs: list[ast.Expr] = [ | |||
| ast.Alias(alias="occurrences", expr=ast.Call(name="count", args=[])), | |||
| ast.Alias( | |||
| alias="occurrences", expr=ast.Call(name="count", distinct=True, args=[ast.Field(chain=["uuid"])]) | |||
There was a problem hiding this comment.
@daibhin found that due to the left outer join for overrides, sometimes events are double counted, which makes this new test I added flakey. Not sure why this doesn't happen on existing tests 🤔 , maybe to do with how/when overrides are set, since I add events after the first flush.
But anyhow, should make this case clear where we never doublecount events.
📸 UI snapshots have been updated2 snapshot changes in total. 0 added, 2 modified, 0 deleted:
Triggered by this commit. |
Problem
^^ Opted to add this to the query runner rather than manipulate filter groups in the frontend because I imagine this can get complicated. Easier to isolate, test and update this logic as and when the search function changes in the backend.
Changes
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Does this work well for both Cloud and self-hosted?
How did you test this code?