Currently telemetry request orders are hardcoded to asc this can lead to situations where the wrong set of limited telemetry is requested. We need to accept incoming order options from views making requests.
Expected vs Current Behavior
We should apply requests based on what views send in.
We are hard coding to ascending.
Impact Check List
[x] Data loss or misrepresented data?
[ ] Regression? Did this used to work or has it always been broken?
[x] Is there a workaround available? (not using limited mode)
[x] Does this impact a critical component?
[ ] Is this just a visual bug with no functional impact?
Steps to Reproduce
Navigate to a telemetry table that has telemetry
Ensure it is in limited mode (toggle at bottom right of telemetry table)
Set time conductor to a large range (1 hr or more)
Hover mouse over pause button
Refresh the browser
Pause as soon as telemetry request is finished (pretty much when pause button becomes visible)
Observe the timestamps for the data is from the beginning of the time range, not the end
Summary
Currently telemetry request orders are hardcoded to
asc
this can lead to situations where the wrong set of limited telemetry is requested. We need to accept incoming order options from views making requests.Expected vs Current Behavior
We should apply requests based on what views send in. We are hard coding to ascending.
Impact Check List
Steps to Reproduce
Environment
Additional Information
Directly related to: https://github.com/nasa/openmct/issues/7636