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.

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

Save last message variant and time received #1525

Open
ctm opened this issue Dec 15, 2024 · 2 comments
Open

Save last message variant and time received #1525

ctm opened this issue Dec 15, 2024 · 2 comments
Assignees
Labels
chore Maintenance or other non-bug, non-feature easy Trivial to do (even when tired!) and semi-worthwhile high priority Should be done fairly soon

Comments

@ctm
Copy link
Owner

ctm commented Dec 15, 2024

Have both the Lobby and each Table record the variant of the message they've received along with a timestamp.

Then put that info into the BrowserError, so we can get some idea of what was last processed when an error comes in. FWIW, this won't necessarily help us with dropped closures (#1523), because it may be that the closure was passed to the JavaScript subsystem in a way that only invokes the closure after a delay. However, being able to compare the client time stamp of when the socket receives a message and when the message is logged as having been sent allows us to get some idea of whether the client clock can be trusted and if not, the approximate offset to compensate by.

@ctm ctm added chore Maintenance or other non-bug, non-feature high priority Should be done fairly soon easy Trivial to do (even when tired!) and semi-worthwhile labels Dec 15, 2024
@ctm ctm self-assigned this Dec 15, 2024
@ctm
Copy link
Owner Author

ctm commented Dec 16, 2024

FWIW, although most messages are tiny, there are a few that are fairly large. The problem with storing only the variant is that the same variant may appear fairly frequently. We could make an enum that is either the actual message itself or the first N bytes of the message's Debug representation. That would prevent us from having to send an entire large message which should be sufficient, since the large ones aren't repeated AFAIK.

@ctm
Copy link
Owner Author

ctm commented Dec 16, 2024

After sleeping on it, just sending up to N characters of the DEBUG representation, regardless of the size is less complex and easily good enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Maintenance or other non-bug, non-feature easy Trivial to do (even when tired!) and semi-worthwhile high priority Should be done fairly soon
Projects
None yet
Development

No branches or pull requests

1 participant