Clarification on Media Device Initialization, Timeout Handling & Retry Logic (Web & Electron SDKs)

Video SDK
1

SDK Type & Version: Zoom Video SDK / Meeting SDK for Web & Electron (JS/TS)

Platform/Device: Web Browsers / Electron (Windows, macOS)

Problem / Context

  • I am referencing the discussion in [Dev Forum Post #135180](regarding delays during audio/video device initialization (`startAudio()` / `startVideo()`).
  • In our testing, hardware/network delays can cause initialization to take significantly long. However, we could not locate official documentation regarding:
    • 1. The **45-second internal timeout** mentioned by Zoom Developer Advocate Vic Yang in the thread.
    • 2. The exact SDK behavior and guidelines surrounding custom timeout wrappers and manual retries.

Questions for Zoom Developer Support:

  1. Documentation Reference: Could you direct us to official documentation or release notes detailing the 45-second internal timeout and state rejection rules for startAudio()`and `startVideo()`?
  2. Handling Hanging Promises: If media devices take an extended period to resolve without throwing an error, what is the Zoom-recommended mechanism for cancelling an ongoing `startAudio()` / `startVideo()` invocation safely?
  3. Electron Specifics: Do Electron applicationsfollow the exact same 45-second promise lifecycle as pure Web SDK apps, or are there native process timeouts to consider? Generally 45s is too long for our app and it continuously getting retried if failed by our users.
  4. Best Practice Confirmation: Is disabling the UI controls and showing loading indicators—while allowing the SDK to implicitly resolve or reject—the only recommended path(Found this on docs), or is there an API method to inspect the device lifecycle phase?
2

Hey @Niki_Jeavio

Sorry for the late reply.

  1. Documentation Reference: Could you direct us to official documentation or release notes detailing the 45-second internal timeout and state rejection rules for startAudio()`and `startVideo()`?

Sorry, we don’t have documentation stating that startAudio has a 45-second timeout — that’s an implementation detail.

Many of our other async methods do have a timeout mechanism, with a default of 10 seconds.

On timeout, they return an error with type = 'OPERATION_TIMEOUT', errorCode = 1. startVideo does not have a timeout mechanism, since we take into account that camera startup and capture is device-dependent and may take longer.

2.Handling Hanging Promises: If media devices take an extended period to resolve without throwing an error, what is the Zoom-recommended mechanism for cancelling an ongoing startAudio() / startVideo() invocation safely?

The startAudio method has a 45-second timeout mechanism, while startVideo does not. Before the timeout is reached, the method call cannot be cancelled.

We will look into improving this behavior in a future release.

  1. Electron Specifics: Do Electron applicationsfollow the exact same 45-second promise lifecycle as pure Web SDK apps, or are there native process timeouts to consider? Generally 45s is too long for our app and it continuously getting retried if failed by our users.

We don’t have any special handling for Electron — the behavior is consistent with the browser.

  1. Best Practice Confirmation: Is disabling the UI controls and showing loading indicators—while allowing the SDK to implicitly resolve or reject—the only recommended path(Found this on docs), or is there an API method to inspect the device lifecycle phase?

Yes.

Thanks
Vic