Global time range in URL overwritten in certain situations.

[walterra]

Found in version

• master onwards since 38dcda0e6bc7719aab94be3d28a0e56c6acef623

Browser

• macos/Chrome

Steps to reproduce

• Move to Discover, set the date picker to something like "last 15 minutes"
• Move to the ML jobs list page, click on one of the jobs list result icons to switch to anomaly explorer

Expected result

• Anomaly Explorer should automatically pick the time range of the job

Actual result

• The time range is the one selected in Discover ("last 15 minutes")

Additional information

• It seems this was introduced by this PR: https://github.com/elastic/kibana/pull/20858
• If you copy the link from the results icon and load it separately in a new window, the timerange gets picked up correctly. So this seems to be an issue with routing and global state in the single page app when moving between pages without completely reloading.

[elasticmachine]

Pinging @elastic/ml-ui

[stacey-gammon]

Sorry for causing this with my PR. I thought that the fix would bring the logic back to where it was prior to June 26th, when angular was removed from the time picker.

Sounds like ML jobs and dashboards stored with time work similarly - when you open them, they should adjust the time, both in the UI and in the URL. That broke for dashboards when angular was removed from the time picker (the URL and the UI got out of sync). My change to fix that was to sync the URL with the UI state. The problem was that it wasn't being initialized on page load.

I'm technically off today but can help more on Monday, and spend some time investigating (or if I find time later today).

[stacey-gammon]

Assuming we start out with timefilter set to Time A. Opening a job URL set to Time B goes through this flow:

1. State.$routeChangeStart
2. this.emit('fetch_with_changes', diffResults.keys); because URL Time changed to Time B.
3. kbnGlobalTimePicker is initialized
4. updateGlobalStateWithTime sets globalState to that stored in timefilter (Time A).
5. globalState.on('fetch_with_changes', function () { syncs timefilter to globalState, but that is now Time A, not Time B.

Why does this work for dashboards?

Assuming we start out with timefilter set to Time A and we open a dashboard with time stored as Time B. Dashboards soft refresh goes like this:

1. this.emit('fetch_with_changes', diffResults.keys); with Time B (same as above). 2. dashboardStateManager.syncTimefilterWithDashboard(_timefilter.timefilter, config.get('timepicker:quickRanges')); updates timefilter to what is stored in the dashboard
2. kbnGlobalTimePicker is initialized

Step 2 stops this bug from appearing because dashboard manually syncs the timefilter to the saved time.

What about when we edit the URL directly, how come the bug doesn't appear then?

In that case kbnGlobalTimePicker is not initialized so we don't hit the bug.

I can actually reproduce this bug now excluding ML completely:

1. Open up a dashboard and set time to Time A
2. Copy the url, paste into an editor, change the global time to Time B.
3. Go to dashboard listing page.
4. Paste the URL into the browser

You'll get a soft refresh that causes the kbnGlobalTimePicker to be re-initialized and the url will end up re-syncing with Time A and losing Time B.

[stacey-gammon]

Not sure of a fix yet, but I think this is not related to ML so I edited the title and labels. It's really a platform/discover team thing, but the de-angularization of time picker was taken on by the Sharing team, as was the fix that caused this additional blocker, so I supposed it's up to us to find a short term solution for 6.4.

Long term, I think this is yet another example of how the tech debt in this area is causing us lost productivity.

[nreese]

@walterra Can you give this change a try - https://github.com/elastic/kibana/pull/21440. It should fix the problems you were seeing

[walterra]

@nreese can confirm that this fixes the issue for me, great!