What source files to look at to combat ipcPromise: onAsk timeout for cmd "PANEL_RUN_COMMAND" error

This is going to be an odd one. I am working with a private fork of RPA that forked around V2.0.2 (3 years ago). I am new to this project but I can tell most of the IPC system (and probably other underlying systems) remained mostly unchanged from V2.0.2.

The error below has been causing automation to fail.

ipcPromise: onAsk timeout 120000 for cmd "PANEL_RUN_COMMAND", args {myJsonObject},"context": {myJsonObject2},"extra": {myJsonObject3}}}"

I see that many topics around this bug and that some fixes have been implemented. I’m attempting to upgrade my repo to be up to date with RPA in hopes of alleviating the solution but there is alot of code, both on RPA’s side and mine to sort through and merge. I was hoping for some guidance as to what pertinent files or specific fixes were implemented in regards to the onAsk error to narrow my search.

I just learned of my repo’s origin with RPA so I must give thanks for the wonderful program your team open sourced.

This error is random and can be showed when internet connection is slow or when there is problem to load a page or element in the page.

A partial solution is set SLOW the !REPLAYSPEED in the part with the error

store | SLOW | !REPLAYSPEED

A definitive solution i can not find.

Thanks for the context. I’ll take a look as to how to transcribe your suggestion into our system. Our users are testing sites while using VPN so internet issues can definitely be a thing.

The error in general has been random for us as well though for some reason we have 1 user test (macro in RPA lingu I think) that always fail on a specific click command on a specific webpage. I guess this example leans towards the page/element having trouble loading.

I also have the same problem and I notice that when the macros are fast it occurs more often, unfortunately I have not found a safe and definitive solution to solve it. It seems to me that it is random, it does not always occur but slow down the execution of the macro it seems to happen more rarely.