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?