You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket should focus on implementing a solution that would allow Snaps to run for a longer period of time that is beyond the current timeout for execution. This is needed mostly for the use cases where cryptographic synchronous operations require longer periods of time to complete their work (e.g. ZK proofs, etc).
Proposal on how to achieve specified requirements:
Provide an endowment in the form of a callback with configuration.
Configuration should specify the time limit for timeout extension.
Callback should contain functionality that should be executed.
When a callback is called, pause the termination timers and reset according to the new time limit requested.
Security related requirements:
Specify maximum time limits that can be requested and used (consider having lowest and highest values).
Prevent calling the callback endowment multiple times while one is already in the state of execution.
Prevent (ignore) nested calls of a callback.
Track a number of the endowment callback calls and make sure there is a limitation to it.
Requirements for future improvements of the UX/UI:
Track current state of long running execution requests in order to provide that information to the UI and other platform's architectural elements, in order to improve user experience.
Notes:
Consider having e2e testing strategy for improvised use case.
This ticket is blocked since September 21st because of architectural obstacle with not having proper requestId communicated between the Snap Controller and Execution Environment
Several approaches to this are presented and communicated on Slack channel in the following thread: https://consensys.slack.com/archives/C02GL38PLE6/p1695301614878949
Since all known solutions to this have tradeoffs it is left to be determined which one would be or if should be acceptable or to search for new ideas around the problem.
This ticket should focus on implementing a solution that would allow Snaps to run for a longer period of time that is beyond the current timeout for execution. This is needed mostly for the use cases where cryptographic synchronous operations require longer periods of time to complete their work (e.g. ZK proofs, etc).
Proposal on how to achieve specified requirements:
Security related requirements:
Requirements for future improvements of the UX/UI:
Track current state of long running execution requests in order to provide that information to the UI and other platform's architectural elements, in order to improve user experience.
Notes:
Consider having e2e testing strategy for improvised use case.
Related resources:
#1483
https://github.com/MetaMask/MetaMask-planning/issues/517
Long running snaps research conclusion document: https://docs.google.com/document/d/1BsL75IiepnS1rbfzOVJ5xX3YS3W79Hmyk725lydsqq8/edit
The text was updated successfully, but these errors were encountered: