Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Staleness indication inconsistency misapplied to layouts based on navigation. #7670

Closed
2 of 7 tasks
jtrack3d opened this issue Apr 5, 2024 · 3 comments · Fixed by #7736
Closed
2 of 7 tasks

Staleness indication inconsistency misapplied to layouts based on navigation. #7670

jtrack3d opened this issue Apr 5, 2024 · 3 comments · Fixed by #7736
Assignees
@jvigliotta
Labels
severity:critical source:community Community contribution or request type:bug
Milestone
Target:4.0.0

Comments

@jtrack3d
Copy link

jtrack3d commented Apr 5, 2024 •
edited
Loading

Summary

The display gets confused when to show / not show staleness indicator after visiting stale providing object in navigation.

I theorize that pub/sub isn't un-subbing somewhere.

Expected vs Current Behavior

If you are on a Display layout where one object/component goes stale, only that component indicates staleness. What I'd expect.

But, if you visit that object directly on the browse navigation (outside a display layout), there after, the staleness affect not only appears on the object/component but the whole display layout whether the object/component is part of the display layout or not. If it is part of the layout, the layout is stale and the subcomponent is stale as well. This seems incorrect.

Steps to Reproduce

  1. Create a Sine Wave Generator (Example) and enable Staleness Updates.
  2. Create a "Display Layout", you can leave it empty.
  3. Click Sine Wave Generator from Navigation - Notice the Staleness indicator occurs occasionally.
  4. Visit the empty "Display Layout", notice it indicates staleness occasionally, though Sinewave isn't on the display.
  5. To compare, visit the display layout, from the browser navigation, drag the sign-wave onto the blank display.
  6. Now you have a display that both the object and the display are showing staleness.
  7. Save the layout, reload the page... visit only the display layout, notice only the sinewave goes stale.
  8. Visit the sine wave generator that is not part of the display, revisit the display and now both display and component go stale.

Environment

  • Open MCT Version: 3.2.1 (Feb Build)
  • Deployment Type: I think it's prod build.
  • OS: Windows 10
  • Browser: Latest Chrome 123, Latest Firefox 115.

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?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?

Additional Information
@ozyx ozyx added this to the Target:4.0.1 milestone Apr 5, 2024
@ozyx ozyx self-assigned this Apr 5, 2024
@unlikelyzero unlikelyzero added the source:community Community contribution or request label Apr 16, 2024
@unlikelyzero
Copy link
Contributor

unlikelyzero commented Apr 16, 2024 •
edited
Loading

VIPER 7670

@unlikelyzero
Copy link
Contributor

Assigning to @jvigliotta

@jvigliotta jvigliotta mentioned this issue May 23, 2024
Merged
14 tasks
jvigliotta added a commit that referenced this issue May 31, 2024
@jvigliotta @ozyx
fix(#7670): Ensure objects unsubscribe from staleness when destroyed (#…
eba6f0f 
…7736)

* clear any staleness subscriptions before viewing a new object

* add checkbox to options for createDomainObjectWithDefaults, update swg staleness provider to use new time api, add test

* revert

* modified for simplification and to remove the need to update helper methods

* consistent naming convention

* Update e2e/tests/functional/staleness.e2e.spec.js

Co-authored-by: Jesse Mazzella <[email protected]>

* adding back vars that were removed

---------

Co-authored-by: Jesse Mazzella <[email protected]>
@jtrack3d
Copy link
Author

jtrack3d commented Jun 3, 2024

Thank you! :) I figured it was an unsubscribe issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jvigliotta jvigliotta

Labels
severity:critical source:community Community contribution or request type:bug
Projects
None yet
Milestone
Target:4.0.0
Development

Successfully merging a pull request may close this issue.

fix(#7670): Ensure objects unsubscribe from staleness when destroyed nasa/openmct
4 participants
@ozyx @jvigliotta @unlikelyzero @jtrack3d