# Intermittent Failures of Layers API with Error: The Zoom client encountered an error while processing the request!

**URL:** <https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835>\
**Category:** Zoom Apps\
**Created:** [August 24, 2022, 8:05pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835 "2022-08-24T20:05:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![vandalayindustries](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vandalayindustries/32/39002_2.png) [@vandalayindustries](https://devforum.zoom.us/u/vandalayindustries)\
**Post date:** [August 24, 2022, 8:06pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/1 "2022-08-24T20:06:00Z")

</div>

**Zoom Apps Configuration**  
React + Node.js. Zoom client Version: 5.11.6 (9890)

**Description**  
After successfully initiating `runRenderingContext`, calls to `drawWebView` or `drawParticipant` very often randomly fail with the error “The Zoom client encountered an error while processing the request!” Subsequent retry calls to the same methods with the exact same parameters eventually succeed.

**Error?**  
Error: The Zoom client encountered an error while processing the request!

**Troubleshooting Routes**

- Not dependent on parameters used to call drawWebView or drawParticipant (as long as they are valid)
- Same affect on various zoom clients

**How To Reproduce**

1. Initialize `runRenderingContext`
2. Calls to `drawWebView` or `drawParticipant`
3. Repeat steps 1 and 2 times, the calls will fail a significant percentage of the time

---

<div class="post-metadata">

**Author:** ![Robert.Wallis](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/robert.wallis/32/38438_2.png) [@Robert.Wallis](https://devforum.zoom.us/u/Robert.Wallis)\
**Post date:** [August 24, 2022, 10:37pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/2 "2022-08-24T22:37:09Z")

</div>

@vandalayindustries Thank you for reporting this issue.

Does this describe what is happening?  
Expected:

- `runRenderingContext` promise success
- then `drawWebView` and `drawParticipant` should immediately work

Actual:

- `runRenderingContext` promise success
- `drawWebView` then you get the above error

I.e. you are waiting for the promise to resolve, but it still errors.

If that’s the case then this is a race condition that we need to solve. I’ll make a bug to track it.

---

<div class="post-metadata">

**Author:** ![vandalayindustries](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vandalayindustries/32/39002_2.png) [@vandalayindustries](https://devforum.zoom.us/u/vandalayindustries)\
**Post date:** [August 26, 2022, 8:06pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/3 "2022-08-26T20:06:09Z")

</div>

Hi @Robert.Wallis , I think that mostly captures it. If the `runRenderingContext` promise returning success actually indicated a ready state to draw that would be ideal.

Just wanted to add that it can easily take 10+ seconds for the drawing to not fail with the above error. So if it’s a race condition, it’s a very slow race. An alternative approach might having an “onReadyToDraw” listener be made available.

---

<div class="post-metadata">

**Author:** ![Robert.Wallis](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/robert.wallis/32/38438_2.png) [@Robert.Wallis](https://devforum.zoom.us/u/Robert.Wallis)\
**Post date:** [August 31, 2022, 10:39pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/4 "2022-08-31T22:39:19Z")

</div>

I see what we are doing differently in our test apps. We both wait for `onRenderedAppOpened` in the sidebar in one app. And also when the app loads we call `getRunningContext` if that returns `inCamera` then we call drawWebView and drawParticipant inside the camera mode webview.

Either method is a good workaround.

---

<div class="post-metadata">

**Author:** ![vandalayindustries](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vandalayindustries/32/39002_2.png) [@vandalayindustries](https://devforum.zoom.us/u/vandalayindustries)\
**Post date:** [September 15, 2022, 8:12pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/5 "2022-09-15T20:12:21Z")

</div>

Hi @Robert.Wallis thanks for the reply. I took a look at both the approaches, but unfortunately finding that neither can be relied upon. Here is a representative issue:

 ![Screen Shot 2022-09-15 at 1.06.56 PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/3X/b/e/bef90cbff993c9bb1edc3769890acfbd4f784d82.png)

To describe what is happening here:

1. runRenderingContext returns success
2. onRenderedAppOpened is called
3. getRunningContext returns “inMeeting” (it seems to return inMeeting instead of inCamera as you wrote above)
4. Drawing API is then called, and randomly fails
5. Repeated calls may or may not work

---

<div class="post-metadata">

**Author:** ![Robert.Wallis](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/robert.wallis/32/38438_2.png) [@Robert.Wallis](https://devforum.zoom.us/u/Robert.Wallis)\
**Post date:** [September 15, 2022, 10:48pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/6 "2022-09-15T22:48:29Z")

</div>

Thanks for the detailed description.

For the `getRunningContext()` solution, on step #3 it should only continue if it’s “inCamera”. This will happen for the web browser that is in the camera, but the sidebar will always be “inMeeting”. The reason to do this is for the app to figure out which view it’s being loaded into, then route to the right code.

For the` onRenderedAppOpened` solution, then the sidebar app (“inMeeting”) will need to wait until after “runRenderingContext” is successful and “onRenderedAppOpened” is returned before calling draw APIs.

I hope that clears it up. Please let me know if it’s still unclear.

---

<div class="post-metadata">

**Author:** ![vandalayindustries](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vandalayindustries/32/39002_2.png) [@vandalayindustries](https://devforum.zoom.us/u/vandalayindustries)\
**Post date:** [September 19, 2022, 7:40pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/7 "2022-09-19T19:40:38Z")

</div>

Hi @Robert.Wallis ,

Thanks for the clarification. I tried again, focusing mainly on the `onRenderedAppOpened` since it seems more elegant to keep all rendering code in the same place. Unfortunately, even when the sidebar has waited for `runRenderingContext ` and `onRenderedAppOpened`, it does not solve the underlying issue. Intermittent failures arise as shown here:

 ![Screen Shot 2022-09-19 at 12.31.53 PM](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/3X/9/0/9014e0678c082f397400038ebb93c773e35e7a40.png)

Appreciate any further insight. Seems to me that there is a real bug here that needs to be addressed.

---

<div class="post-metadata">

**Author:** ![Robert.Wallis](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/robert.wallis/32/38438_2.png) [@Robert.Wallis](https://devforum.zoom.us/u/Robert.Wallis)\
**Post date:** [September 20, 2022, 4:40pm UTC](https://devforum.zoom.us/t/intermittent-failures-of-layers-api-with-error-the-zoom-client-encountered-an-error-while-processing-the-request/74835/8 "2022-09-20T16:40:56Z")

</div>

Thanks this is good feedback. My team will try to reproduce this bug and put breakpoints at all the places where it could return the generic “The Zoom client encountered an error” error so we can figure out why it’s failing.
