Dashboard doesn't display results if user navigates to open dashboard from discover

[bhavyarm]

Kibana version: 7.7.0 BC9

Elasticsearch version: 7.7.0 BC9

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: If user clicks on a open dashboard using dashboard icon in side nav from discover, dashboard doesn't display any results.

Please note:

1. Doesn't happen when async search is turned off (batch request set to true in advanced setting)
2. Happens in default and non-default spaces
3. Workarounds are - user reopening the dashboard from dashboard listing table or doing some state management on the dashboard

Steps to reproduce:

1. Install sample data dashboards and pick your favourite - I picked flights
2. Click on discover on side nav - and pick flights data in index picker - Kibana displays results
3. Click on dashboard on side nav- open flights dashboard from dashboard listing table- Kibana displays results
4. Click on discover again on side nav and change the time to 1 year - Kibana displays results
5. Click on dashboard from side nav - Kibana doesn't display results on the open flights dashboard and there are no console errors.

Expected behavior:
Kibana should handle state mangement better.

Screenshots (if relevant):

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[bhavyarm]

cc @lukeelmers @LeeDr

[flash1293]

I can see in the screenshot TSVB is rendering fine, this seems to be related to the search service. Maybe some pending tasks hanging from the discover search?

[Dosant]

Seems like it isn't reproduced in master. But I was able to reproduce in 7.7 branch.

I thought that this commit could fix the issue in master, #63199, but putting it on top of 7.7 didn't fix the issue.

[bhavyarm]

@Dosant we are testing 7.7.0 and not on master because this is release testing. Let me know if you need more answers or help. Thanks!

[lizozom]

@bhavyarm can you share the network and console outputs from the browser?

[Dosant]

Some updates after debugging together with @lizozom:

1. we don't have a solution yet
2. looks like the bug isn’t inside async search. We were able to reproduce it in basic with sync search strategy turned on. (just disabled async search in code)
3. We are able to reproduce bug on a specific vis combination in dashboard:
   minimal reproduction.zip. Apparently to get into this state it needs a map and vis which fires multiple search request, in example: bar chart with histogram agg. Removing one of those is fixing the dashboard.
4. We can't reproduce it in OSS, because there is no map. We didn't find another combination to reliably reproduce using just OSS types.
5. We suspect this could be somewhat similar to Dashboard - Error in visualization: [esaggs] > Aborted (many #60596
6. Can't reliably reproduce in master, but can in 7.7

cc @ppisljar

[bhavyarm]

Reproduced this on BC10 on production cloud instance

[Dosant]

We figured it out and have 2 candidate prs. Please find explanation in the pr description.
tldr: there is a chance that canceling a search could also trigger a cancelation of another search.

1. Option 1: Backporting [SEARCH] Cleanup fetch soon #63320 which fixed this in Master and 7.x. It touches a dozen of files :(. But this would be a proper code paths fix. Fix "Dashboard doesn't display results if user navigates to open dashboard from discover" - Option 1 #64998
2. Option 2: Tiny fix which nicely workarounds this issue. touches 1 file. Fix "Dashboard doesn't display results if user navigates to open dashboard from discover" - Option 2 #64999

@lizozom, @ppisljar, @lukasolson, I guess we need to decide if we comfortable with rolling out Option 1? Otherwise Option 2 seems like a clear and to the point fix.
Because I don't know search infrastructure well, I personally feel more comfortable with Option 2

@LeeDr, I pulled your test into both prs #64964. Not sure if it was finished or if it needs more work

[ppisljar]

at this point for me option 2 is preferred, it fixes fetchSoon to behave correctly when 0ms is passed in (which we should do anyway) and also fixes this bug with a really small change. we should also merge this to master.

[Dosant]

Merged: #64999 (Option2) into 7.7