-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Staleness] Functionality in telemetry component views and API #6109
Comments
Testing
|
Testing Resources and ReferenceHere's an exported folder with many elements to aid testing. Mostly @jvigliotta with some tweaks from @charlesh88. Flex Layout with stale elements Display Layout with stale elements Display Layout not stale |
* initial telemetry api updates for staleness support * modifying staleness to a subsription style * fixing variable name * debuggin * put the subscribe in the wrong place * stale class for object views * temp cyan border for testing * added staleness to swg, working on stacked plot staleness * WIP: stacked plot staleness * reverting, going a different route * staleness on stacked plots * plot legend staleness * remove debug code * staleness for alphanumerics * lad table and table set staleness * overlay plot staleness * remove debug code * hardened lad staleness functionality fixed plots without composition bug * adding staleness to gauges * renaming telemetry age check functionality so it does not conflict with new staleness functionality * couple one-off fixes here and there, and WIP for condition sets, moving to telemetry tables to facilitate styling of completed components * small fix on lad tables, added staleness functionality to tables * finishing up condition sets * some cleaning up * adding border to condition sets when an item is stale * fixing dub sub * addressing PR comment, moving repeated code to a function * robustified the SWG stalenes provider, little fixes here and there as far as cleaning up listeners and... whatnot * removing debug code * typo fixes * cleanin up debug code * created a simple stalenes mixin for more basic usage in components * more robustification, if a new staleness subscription happens, will now send the current staleness value if we have it, beefed up example stalenes swg provider * beefed up staleness mixin a bit to give it more use * copyright * cleanin up ladtable code * cleanin up ladtable code * cleaning up lad table sets * some minor updates * Closes #6109 - New staleness glyph and font CSS added. * Closes #6109 - Normalized staleness colors as theme constants. - New mixins for staleness application to view elements. - Applied staleness styling to all relevant view elements. - TODO: smoke-test in Show theme. * adding staleness utils helper, mixin and isStale functionalirty for telemtry api * Closes #6109 - Refined style for Snow theme. * need to have one domainObject per stalenes utility * making sure we handle domains correctly while dealing with staleness * couple fixes * moving abort controller logic to a spot where it makes more sense * added some more info for the StalenesProvider interface docs * returning undefinded for ifStale requests with no provider * debuggin * debuggin * missed "isStale" call in condtioncollections * removing debug code and using mixin unsubscribe in gauge * fixing tests * more targeted tree item click Co-authored-by: Charles Hacskaylo <charlesh88@gmail.com> Co-authored-by: Andrew Henry <akhenry@gmail.com> Co-authored-by: Scott Bell <scott@traclabs.com>
Cannot be tested until YAMCS is updated |
Testathon 2/2/23: Most of this is all working and super cool. I only found these two things
|
Verified fixed - Testathon 02-09-2022 |
@michaelrogers to test |
Fix verified during testathon 02/13/2023. Staleness indicators work as expected in the above listed scenarios. |
Is your feature request related to a problem? Please describe.
Users need a way to know if the telemetry they are viewing is stale. Decisions made assuming telemetry is fresh could have a negative effect if the telemetry is in fact stale. Having a way to know for sure if telemetry is stale or not is very useful.
Describe the solution you'd like
Open MCT should have the ability (through the API) to add "Staleness Providers" these would be handled on the telemetry serving side and Open MCT would have no knowledge of their inner-workings, but would be able to respond and alert the user when it is notified through the provider that a telemetry endpoint has become stale.
Describe alternatives you've considered
We currently have a rudimentary way of doing this with Condition Sets. They have a way of tracking the time since a telemetry endpoint last received any data. This is configurable, but it is a fixed time interval and it's not based on any server side knowledge.
The text was updated successfully, but these errors were encountered: