-
Notifications
You must be signed in to change notification settings - Fork 1
feat: add server side heartbeat signal message case #170
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds support for server-side heartbeat signal messages in the StreamingClient. The primary change is handling the new HEARTBEAT signal message action type to prevent unnecessary error logging for this expected message type.
Key changes:
- Added a case for
SignalMessageAction.HEARTBEATin the signal message handler - Changed the default case logging from
console.errortoconsole.warnfor unknown signal types
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No issues found across 1 file
| case SignalMessageAction.HEARTBEAT: | ||
| break; | ||
| default: | ||
| console.error( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why change the level? If we do something similar in the future, the warning might be ignored, which we might not want?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes more sense as a warning rather than error as it's not "breaking", i.e. it's not something that stops the app functioning and shouldn't ever be. In that case we'll do a major version bump :)
It'll still log to console all the same, just at a lower level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think error was always the wrong choice here, as this can get triggered by any future extensions to the signal message options which is likely and anyone not on the latest version from the point of release will get hit with errors, when from their point of view nothing has gone wrong. We have to make the changes backwards compatible anyway to prevent breaking existing clients so a warning to upgrade felt more appropriate than an explicit error. If I was using a package and that package starting throwing errors even though I hadn't changed anything and everything appeared to still be functioning I would probably consider it bad DX.
robbie-anam
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| case SignalMessageAction.HEARTBEAT: | ||
| break; | ||
| default: | ||
| console.error( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes more sense as a warning rather than error as it's not "breaking", i.e. it's not something that stops the app functioning and shouldn't ever be. In that case we'll do a major version bump :)
It'll still log to console all the same, just at a lower level.

Summary by cubic
StreamingClient now handles server-side HEARTBEAT signals as a no-op to avoid false errors. Unknown signal actions now log a warning instead of an error to reduce noise.
Written for commit ee1ac4c. Summary will update automatically on new commits.