-
Notifications
You must be signed in to change notification settings - Fork 8.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
add autoRefreshFetch event to timefilter #20863
Conversation
@@ -71,6 +72,7 @@ export class EmbeddedVisualizeHandler { | |||
this._vis.on('update', this._handleVisUpdate); | |||
this._vis.on('reload', this._reloadVis); | |||
this._uiState.on('change', this._fetchAndRender); | |||
timefilter.on('autoRefreshFetch', this._fetchAndRender); |
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'm not 100% sure what the forceFetch
parameter does, but I think it means it won't refetch data unless the vis params has changed so we probably want to use this._reloadVis
as the listener here, just like we do for the reload
event on this._vis
.
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.
Yeah I would agree with Spencer here. forceFetch
will actually be passed to the request handler, and it should use it to ignore every possible caching it has. In case of the courier request handler, that means, it won't check if any configuration/timeRange, etc actually changed, and instead always query again. So we will need this for auto refresh, since in case of auto refresh no configuration change, so please replace that by calling this._reloadVis
.
💚 Build Succeeded |
@@ -71,6 +72,7 @@ export class EmbeddedVisualizeHandler { | |||
this._vis.on('update', this._handleVisUpdate); | |||
this._vis.on('reload', this._reloadVis); | |||
this._uiState.on('change', this._fetchAndRender); | |||
timefilter.on('autoRefreshFetch', this._fetchAndRender); |
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.
Yeah I would agree with Spencer here. forceFetch
will actually be passed to the request handler, and it should use it to ignore every possible caching it has. In case of the courier request handler, that means, it won't check if any configuration/timeRange, etc actually changed, and instead always query again. So we will need this for auto refresh, since in case of auto refresh no configuration change, so please replace that by calling this._reloadVis
.
@@ -270,6 +270,7 @@ function VisEditor( | |||
|
|||
timefilter.enableAutoRefreshSelector(); | |||
$scope.$listenAndDigestAsync(timefilter, 'timeUpdate', updateTimeRange); | |||
$scope.$listenAndDigestAsync(timefilter, 'autoRefreshFetch', updateTimeRange); |
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 won't need that. Since another auto refresh trigger, will never cause the time to actually change, since timefilter.getTime()
will return the still stringified from
/to
, like "now-7d". Have you experienced any issues without that listener?
💔 Build Failed |
💔 Build Failed |
jenkins, test this |
💔 Build Failed |
Jenkins, test this |
💔 Build Failed |
Jenkins, test this |
💔 Build Failed |
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 adds the concept of visualize reaching out to some global context and knowing about implementation details of other systems in order to work correctly.
this is something we were trying to remove (and of course broke auto refresh in the process 🥇 )
i would suggest we keep to the idea of visualize having no idea about the outside world and move the responsibility of handling autorefresh to the embedding app.
@timroes what do you think ?
@ppisljar I think the proper long term solution is to build an own service for auto refresh as Nathan discussed with Spencer (see #20813 (comment)). Though I think for a short term solution (since this will block 6.4) release and that auto refresh service should be properly design, this is a viable solution I would be willing to go with. |
💚 Build Succeeded |
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.
LGTM as its a working solution and its a blocker and as we have a plan on how to improve it in the long run.
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.
Code LGTM as a short term solution, but we'll still want to create a proper auto refresh service (@nreese could you perhaps open another ticket for that, so it won't be forgotten?).
Tested in Chrome Linux, auto refresh now works fine on dashboard and in visualize again.
* add autoRefreshFetch event to timefilter * replace fetchAndRender with reloadVis remove listener from editor * unsubscribe correct handler
short term fix for #20813
SearchPoll emits the timefilter event
autoRefreshFetch
when the auto refresh interval is reached. Visualizations subscribe to this event and fetch data.cc @timroes @stacey-gammon @markov00 @cjcenizal