Consider updating Snap RPC timeouts

[ritave]

Currently, the timeouts are set to a low value of 60 seconds. It can interfere with long-lasting calculations, such as calculating an RSA-4096 key used in some blockchains. Simply updating timeouts to a higher value might also interfere with other calculations we might not foresee (basic example would be generation of vanity addresses).

Another basic use-case is using snap_confirm inside a rpc request. The RPC can timeout waiting for user response.

Since all RPC in Snaps are only localhost, there can't be actual network problems interfering with the commands. Only reasons the RPC takes a long time is because there are either actual calculations taking place in a Snap or it has entered a bad state, such as an infinite loop, and is causing a service denial. Due to our previous testing of running 100 Snaps at the same time, neither of both reasons are an actual problem to the functioning of Metamask extension.

Thus my suggestion is:

• [ ] Move away from timeouts (or set them to really high values)
• [ ] Drop RPC connections when no origin is connected to the Snap.
• [ ] (optionally) Add ability for DApps to cancel RPC requests

This would be consistent with how browsers treat fetch calls. For example, Chrome has a default timeout of 300 seconds and cancels requests when the user navigates out of the page.

[rekmarks]

Currently the following timeouts exist in the relevant modules. They are all configurable, but we currently just use the defaults:

• SnapController:
  • The maximum request processing time (maxRequestTime, 60 seconds)
  • The time a snap has to process a JSON-RPC request before being terminated.
  • This is the timeout referred to in the original issue comment.
  • The maximum idle time (maxIdleTime, 30 seconds)
  • The time a snap may run without receiving any new requests (assuming it is not processing any).
• AbstractExecutionService (the base class for all execution services)
  • The unresponsive timeout (unresponsiveTimeout, 30 seconds)
  • The time that a snap has to respond to ping messages before it is terminated.

There are also intervals in the above modules but they are implementation details that should not affect the relevant behaviors.

@ritave, I believe your recommendation is referring to the maxRequestTime. Are the other timeouts related to this issue or should we consider them to be out of scope?

[ritave]

The Snap can execute setTimeout() inside an RPC request, which will execute after the eval finishes. The setTimeout() will be execute during idle time and so would have a 30 second timeout instead of the one reserved for RPC requests.

[ritave]

We talked with @rekmarks and decided that all timeouts systems needs to be refactored along with redesigning the snap's lifecycle

[veronicaz41]

FYI, we encountered the same issue and recommend to make timeouts configurable: https://github.com/MetaMask/metamask-extension/pull/14256

[ritave]

We added endowment:long-running permission. Closing