Cannot start share view due to OPERATION_TIMEOUT error

Description
When user A shares the screen by calling stream.startShareScreen(videoElement), other users in the room receive the active-share-change event and then call stream.startShareView(canvas, activeUserId).

User A has successfully started sharing, however other users in the room encounter an error when calling startShareView:

{"type":"OPERATION_TIMEOUT","errorCode":1}

This issue is quite difficult to reproduce and has only occurred once so far.

Please check for me with the session ID: YjevI/qFSCi1e4iXtF3XuA==

Browser Console Error

{"type":"OPERATION_TIMEOUT","errorCode":1}

Which Web Video SDK version?
2.2.5

Device:

  • Device: Windows PC
  • OS: Window 10 version 22H2
  • Browser: Chrome
  • Browser Version: 140.0.7339.129

Hey @phuongnv1

Thanks for your feedback.

YjevI/qFSCi1e4iXtF3XuA==

From the log analysis, it seems that when calling stream.startShareView, the result was not awaited with then or await before calling stream.stopShareView. This caused a race condition, where the earlier method did not successfully reach a completed state and instead timed out.

The logs also show that subsequent calls to stream.startShareView succeeded, so the sharing feature is working properly.

Thanks
Vic

Hey @vic.yang

Thank you for your feedback.

From the log analysis, it seems that when calling stream.startShareView, the result was not awaited with then or await before calling stream.stopShareView.

I understand your point, but after checking the code I noticed that there is already an await. I still don’t understand why there is a difference between the sharing attempts.

For session NqnbCwjjSYCCnrd7T/kTDw==, could you please explain why the first two shares were successful but the third one failed as mentioned in this issue? Ideally, it would be helpful if you could also add timing information for each call so that I can better understand where the problem lies.

I would greatly appreciate your response.

Thanks

Phuong

Hi @phuongnv1

YjevI/qFSCi1e4iXtF3XuA==

2025-09-23T03:57:36.566 startShareView 16782336
2025-09-23T03:57:36.688 stopShareView
2025-09-23T03:57:36.691 stopShareView success
2025-09-23T03:57:36.693 startShareView 16782336
2025-09-23T03:58:18.315 stopShareView
2025-09-23T03:58:18.317 stopShareView success
2025-09-23T03:58:36.591 startShareView timeout :cross_mark:

Thanks
Vic

1 Like

Hey @vic.yang

Thank you for your feedback.

I’m trying to check the timing of calls with session ID NqnbCwjjSYCCnrd7T/kTDw==. According to our logs, this session makes 6 calls at 3 different time intervals.

2025-09-29T03:04:21.088 stopShareView

2025-09-29T03:04:21.092 startShareView 16785408

2025-09-29T03:04:21.140 stopShareView

2025-09-29T03:04:21.147 startShareView 16785408

=> This time it was successful.

2025-09-29T03:04:56.905 stopShareView

2025-09-29T03:04:56.910 startShareView 16786432

2025-09-29T03:04:57.007 stopShareView

2025-09-29T03:04:57.016 startShareView 16786432

=> This time it was successful.

2025-09-29T03:06:00.074 stopShareView

2025-09-29T03:06:00.078 startShareView 16787456

2025-09-29T03:06:00.160 stopShareView

2025-09-29T03:06:00.162 startShareView 16787456

=> This time I got 2 errors from startShareView:

{"type":"OPERATION_TIMEOUT","errorCode":1}

Could you explain the timing between the calls to help me understand why the first two intervals were successful but the third one failed?

I look forward to your response.

Thanks

Phuong

Hi @phuongnv1

Could you explain the timing between the calls to help me understand why the first two intervals were successful but the third one failed?

Sorry, I can’t explain why there is this difference, but as I mentioned earlier, we recommend waiting for startShareView to get resolved before calling stopShareView; otherwise, a race condition may occur.

Thanks
Vic

We’re also having this issue. We’re listening for the active-share-change event, and if the share is active we try to start the share view. But as already mentioned, we also get {type: "OPERATION_TIMEOUT", errorCode: 1}. It doesn’t happen for all sessions so its also difficult to reproduce.

These are the sessions where this is happened
SLLabZO8RhGfYZF4d+TKYw==
X6w/Oo1TTaiinFKt1cd4Lg==
2ohGn8ipTHeNg1YBHRLK0g==

Which Web Video SDK version?
2.3.0

Device:

  • Device: Windows PC

  • OS: Windows 10+

  • Browser: Chrome

  • Browser Version: 143

Hey @marvinbene

Thanks for your feedback.

SLLabZO8RhGfYZF4d+TKYw==

Sorry, this session is already over a month old, and it’s difficult for us to get the corresponding detailed logs.

X6w/Oo1TTaiinFKt1cd4Lg==

After analyzing the logs, we found that the Native SDK user shared content with a size of 0×0. When the Chrome user tried to render it using stream.startShareView, it couldn’t be drawn, so an error was thrown.

2ohGn8ipTHeNg1YBHRLK0g==

Around 2025-12-16T21:59:43 GMT, the content shared by the Native SDK user was normal and had a valid size, but by 2025-12-16T22:01:54 GMT, the size became 0×0 again, which caused rendering issues on the receiving side.

Thanks
Vic