Skip to content

Update client error handling#1667

Open
mhoyer-streamlabs wants to merge 2 commits intostagingfrom
mh-update-client-error-handling
Open

Update client error handling#1667
mhoyer-streamlabs wants to merge 2 commits intostagingfrom
mh-update-client-error-handling

Conversation

@mhoyer-streamlabs
Copy link
Copy Markdown
Contributor

@mhoyer-streamlabs mhoyer-streamlabs commented Apr 9, 2026

Description

Update client error handling to ensure all errors are passed along to the front end by replacing conn->call with conn->call_synchronous_helper and parsing the return. In some streaming/recording/replay buffer cases, clear the existing object ref and don't set the new one if the back end call fails. Replaced std::vector<ipc::value> with auto to shorten calls and make them easier to read.

Motivation and Context

Some important errors were being ignored.

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • Tweak (non-breaking change to improve existing functionality)
  • Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

  • The code has been tested.
  • All commit messages are properly formatted and commits squashed where appropriate.
  • I have included updates to all appropriate documentation.

@mhoyer-streamlabs mhoyer-streamlabs changed the title Update client error handling - WIP Update client error handling Apr 10, 2026
usesStream = false;
auto response = conn->call_synchronous_helper(className, "SetRecording", {ipc::value(this->uid), ipc::value(UINT64_MAX)});
ValidateResponse(info, response);
usesStream = true;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Why did you change usesStream = true; ? This changes the behavior entirely. Likely a copypaste issue.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Definitely looks like copy/paste. Although should we even set this here? If setting the new recording object fails and we're going to leave the previous object, shouldn't we leave the previous value of this var as well?

usesStream = false;
auto response = conn->call_synchronous_helper(className, "SetRecording", {ipc::value(this->uid), ipc::value(UINT64_MAX)});
ValidateResponse(info, response);
usesStream = true;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

usesStream = true;
The same here.


void osn::Streaming::SetVideoEncoder(const Napi::CallbackInfo &info, const Napi::Value &value)
{
if (!videoEncoderRef.IsEmpty())
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Resetting the cached ref before the IPC call succeeds can leave the wrapper out of sync with the backend. If SetVideoEncoder rejects the new encoder, the backend keeps the old encoder but videoEncoderRef has already been cleared, so the client starts returning undefined. Can we move the reset until after ValidateResponse succeeds?

This same pattern also appears in other places.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

You are correct - I was thinking a backend failure meant no encoder stored, but I see now that it actually keeps any previous value in both client and server. My thought was not to store the previous value in an error case, but I only updated half of that. I'll move those statements back down so the previous value remains.

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.

3 participants