Plots in a Tabs View don't re-query when Time Conductor toggled to Local Clock

[charlesh88]

Summary

1. Place a Stacked Plot with some real-time data in a Tabs View.
2. Put the Time Conductor (TC) in Local Clock (RT) mode. Verify that data is visible that has some distinct values to it.
3. Switch the TC to Fixed mode, then wait for a minute or two.
4. Switch the TC back to Local Clock.

Observe: the plot will draw traces from the time in which the TC was switched to Fixed mode directly to the time in which it was switched back to RT. This may not be the case for all plots, see this example:

It should have re-queried and filled in the data for all plots in the view.

Impact Check List

• Data loss or misrepresented data?
• Regression? Did this used to work or has it always been broken?
• Is there a workaround available?
• Does this impact a critical component?
• Is this just a visual bug with no functional impact?

Environment

• Open MCT Version: 1.8.3
• Deployment Type: /stable
• OS: Mac
• Browser: Chrome

Additional Information

[davetsay]

We need to make sure when fixing this that eager load true does not break. the requests (that aren't happening) @charlesh88 is talking about should happen for the current tab and also all other tabs. Then, on tab change no new requests should be made.

[charlesh88]

Repro steps update: initially it was thought that Eager load had to be set true, but we just retested during Testathon today and determined that the setting doesn't matter.

[shefalijoshi]

Testing instructions:
View a plot with good data.
Switch between Local Clock and Fixed time span and ensure that data is requested for the bounds given.

[akhenry]

Not fixed. I am seeing cases where loading a plot in real-time mode does not show a spinner, and sometimes does not show historical data at all. In this case the request goes out and returns, but the data is never painted in the plot.

I am also seeing duplicate requests when switching between modes.

[akhenry]

The issue here is actually that historical data retrieval is extremely slow in the test environment, and there is no visual indication provided to the user that historical requests are still outstanding. ie. there is no spinner being shown.

In attempting to reproduce this, the plot did eventually fill in the missing data, it's just taking several minutes for Yamcs to return historical data at times due to .

I do not think that the answer to this is to show the spinner in this case, we should not prevent the user from seeing the data already in the plot, but we should tell them subtly that we are fetching the "missing" data.

Created #5219 to track missing spinners

[akhenry]

We should re-test the issue as originally reported and verify that it is actually fixed. There is a secondary issue of plots not showing a spinner when historical queries are outstanding, which I will create a separate issue for.

[davetsay]

verified

[unlikelyzero]

We need an explicit test for this