Display became inoperable

[davetsay]

Summary

In a production deployment, a complex display - which relies on a Remote Clock - became inoperable. Troubleshooting resulted in the following analysis. 1) the remote clock never receives a time via historical request. 2) The main event loop is getting blocked with style recalculations, so it fails to process telemetry values, including the current time via subscriptions. The Remote Clock relies on getting time via telemetry request or subscription. Other telemetry requests rely on Remote Clock having a time set, so they in turn get stalled.

Fix these

1. Remote Clock never receives telemetry from a historical request, due to a code regression.
2. Progress bars are very CPU intensive.
3. Plans are polling to resize internal components due to window resizes.

Expected vs Current Behavior

The Remote Clock gets a time set and telemetry begins to flow and views render properly

Steps to Reproduce

See VIPERGC-415 for full instructions, or...

Poor Man's Steps to Reproduce

1. Build a complex display with all the things
2. Configure to use Remote Clock
3. Open complex display on multiple (at least 3) windows
4. Refresh displays in sequence until they get stuck loading and never resolving

Environment

• Open MCT Version:
• Deployment Type:
• OS:
• Browser:

Impact Check List

• [x] Data loss or misrepresented data?
• [x] Regression? Did this used to work or has it always been broken?
• [x] Is there a workaround available? Navigate to another view first to set remote clock, then navigate to complex display
• [x] Does this impact a critical component?
• [ ] Is this just a visual bug with no functional impact?
• [ ] Does this block the execution of e2e tests?
• [x] Does this have an impact on Performance?

Additional Information

[davetsay]

Testing Instructions:

• See Steps to Reproduce, and ensure you get the page to load properly in the scenario described
• Testing Progress Bars
  • go to a display that has a bunch of progress bars (plots, telemetry tables, etc.),
  • Open the Chrome Task Manager and filter by CPU descending
  • Throttle your network connection in the Chrome dev tools, or even halt it completely before all requests resolve, to get the progress bars to stay spinning
  • Observe in the Task Manager in your best judgement that the CPU isn't going out of control.
• Testing PlanView
  • Observe plans and their contents resize accordingly when you resize the window, add to its composition, etc.

[unlikelyzero]

after syncing with @davetsay ,

1. Progress bars are already tested with a visual test
2. Planview resizing is already tested with a visual test
3. We need to figure out how to add a test to cover the remote clock / timeContext changes

[akhenry]

@shefalijoshi to test

[shefalijoshi]

Verified fixed over VPN. @unlikelyzero to verify this in the dev lab