-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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(data-exploration): bugfixes and improvements #13461
Conversation
…s. Create HogQLExpression
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.
A few thoughts but nothing blocking
(I didn't run this :D)
As discussed at standup really we need at least E2E tests on this. Would be good for the storybook section to have a "how do I start using data exploration" page too
@@ -74,11 +71,13 @@ const PropertyFormulas: EventsQuery = { | |||
|
|||
const PropertyFormulasTable: DataTableNode = { | |||
kind: NodeKind.DataTableNode, | |||
full: true, |
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.
Is this something more like showAllTableChrome
?
full
feels too vague
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.
Normally I'd agree, but in this case I'm hoping we can convert this into a common notation that's easy to use everywhere.
E.g. { kind: 'DataTableNode', full: true, source: {} }
, { kind: 'SessionRecording', full: true, id: 'http://' }
, { kind: 'InsightViz', full: true, source: {} }
If you pass full: true
, you get the full scene with our curated set of widgets and tools. Without full
, we just display the element (recording, graph, etc). Then you can control it more with various showBla: true
.
I wanted it to be different from the other showOneThing
keywords. I thought about "Chrome", but 1) it's a browser sadly and I do know where its name comes from, 2) some of the OtherThings
in showOtherThings
are not "chrome".
When in doubt, the simpler solution wins, so full
it was 😅
actions.setElapsedTime(performance.now() - now) | ||
return data | ||
} catch (e: any) { | ||
cache.abortController = null |
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 don't think we need to reset the abortController.
It's safe to call abort after a call is finished, and we reset to a new controller when we start the next API request
loadData: async () => { | ||
return (await query<DataNode>(values.query)) ?? null | ||
loadData: async (_, breakpoint) => { | ||
if (cache.abortController) { |
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.
We also need to be able to trigger the abort from outside the component. There are two triggers
- (covered here) a new API request is started
- In case of navigating away from a page
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 added an abortQuery
action
} catch (e: any) { | ||
cache.abortController = null | ||
if (e.name === 'AbortError' || e.message?.name === 'AbortError') { | ||
return values.response |
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.
we also need to call in to the cancel
API with a query id when the API call is cancelled so we can release any ongoing ClickHouse resource usage
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.
And we need to make sure this is reporting timeToSee
data too.
Although fine to do all of this as follow-up since this is behind a flag
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.
happy to do this in a followup 😅
if (values.autoLoadRunning) { | ||
actions.stopAutoLoad() | ||
} | ||
if (cache.abortController) { |
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.
For simplicity, I've removed this elsewhere. In practice turbo mode means we're not unmounting the logics early enough to make a difference
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.
hmm... makes sense, though if all data goes through this dataNodeLogic, then we'll have cases where cancelling this before unmount will pay off... So I'd keep it. I changed it a bit to go through a new abortQuery
action
Thanks for the reviews! I cleaned up a few things, and already had to merge with master. Since this PR lightly touches a lot of files (most of which are behind a flag), and fixes a few bad bugs, I'd happily merge this in and volunteer for oncall support for it over the next days 😅. Otherwise I fear work on other data exploration tasks next week will yield in a lot of annoying merge conflicts... |
* update schema * slight touchups * always use the latest query from props * useCallback to memoise setQuerySource * handroll some debouncing * add full:true * fixes * make only EventsQuery-s queriable. EventsNode is just used in insights. Create HogQLExpression * yeet EventsNode from data table, support loading next results * get new results working again * remove default sorting if editing the live events page * fix test * query cancellation * show query time in the interface * load next people * more fixes * more fixes * last touchers * fix sorting again * combine some aborting
Problem
Data exploration is not over the line yet, which means it's not live and enabled for some users.
Changes
Tries to take it over the line. In scope (might change):
dataNodeLogic
It should again work stable enough that we can enable the flag for ourselves.
Will get to in the next PR
Planned to, but didn't manage to get this in here.
renderInBetweenRowOrNull(prev, next)
or something like thatOut of scope for now
query_event_list.py
andevent.py
How did you test this code?