-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long running Snaps for synchronous work #1604
Comments
From standup: David needs some input from Erik on endowment copy, etc |
Suggested metadata
|
Will create another ticket in MetaMask-planning and mark this as blocked |
This ticket is blocked since September 21st because of architectural obstacle with not having proper requestId communicated between the Several approaches to this are presented and communicated on Slack channel in the following thread: https://consensys.slack.com/archives/C02GL38PLE6/p1695301614878949 |
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: