-
Notifications
You must be signed in to change notification settings - Fork 136
Description
I’m not quite sure if this is a bug or a feature request. There’s a problem related to starting recording on VMs with slow disks. When the start egress request is made, the application (egress) recognizes the request and initiates the recording procedure but crashes with an error (websocket timeout). In fact, as I found out, the error isn't related to the websocket; it is thrown by the library that launches Chrome (a timeout on starting Chrome due to slow reading from the disk into RAM).
This creates a scenario where you start a VM with egress and begin making recording requests, which fail (up to 30+ attempts), but once one attempt succeeds, all subsequent attempts are guaranteed to succeed. If you use a disk with acceptable speed, this error never occurs.
I would like the ability to configure this timeout or at least significantly increase it, as otherwise, I have to use a fast disk in a scenario where it is only needed to read Chrome into RAM once. Alternatively, we could try working without the timeout and guarantee reading Chrome from the disk before accepting the first recording request when starting egress (not the recording, but the application itself). I’m not a Go developer at all, and the solution shouldn’t be complicated, but I’m unlikely to figure it out in this language. Thank you.