Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Clear/Preserve State based on WS session id #354

Closed
banisadr opened this issue Oct 26, 2022 · 3 comments
Closed

Clear/Preserve State based on WS session id #354

banisadr opened this issue Oct 26, 2022 · 3 comments
Labels
feature A new feature or idea

Comments

@banisadr
Copy link

Depends on: foxglove/ws-protocol#256

Need to clear or preserve state in studio when using WS connection based on session id. If reconnecting to the same session, then state should be preserved because we are recovering a dropped connection. If session id changes, we should clear state to properly display data.

Context: Customer is reconnecting to a websocket in a different context and state is being preserved even though a different program is actually being run. Its results in broken and confusing results in studio. It is not sufficient to always clear state on new connection because we may be re-connecting a dropped connection in which case state should be preserved.

@jtbandes
Copy link
Member

Currently, state will be cleared when the receiveTime of incoming messages goes backwards. I recommend the customer try sending a message with time zero when the connection needs to be reset.

@amacneil
Copy link
Contributor

@jtbandes do you know if we respect and clear state if the /run_id parameter changes?

@jtbandes
Copy link
Member

Definitely not with the foxglove websocket since it doesn’t support params 😀
Also I don’t believe we use /run_id in the ROS native players either.

@amacneil amacneil transferred this issue from another repository Dec 16, 2022
@foxglove foxglove locked and limited conversation to collaborators Dec 16, 2022
@amacneil amacneil converted this issue into discussion #430 Dec 16, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
feature A new feature or idea
Development

No branches or pull requests

3 participants