Skip to content

Conversation

@ao-anam
Copy link
Contributor

@ao-anam ao-anam commented Nov 26, 2025

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.

Copilot AI review requested due to automatic review settings November 26, 2025 15:54
Copy link

Copilot AI left a 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.HEARTBEAT in the signal message handler
  • Changed the default case logging from console.error to console.warn for unknown signal types

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link

@cubic-dev-ai cubic-dev-ai bot left a 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(

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@robbie-anam robbie-anam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

case SignalMessageAction.HEARTBEAT:
break;
default:
console.error(
Copy link
Contributor

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.

@ao-anam ao-anam merged commit 93838e4 into main Nov 26, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants