-
Notifications
You must be signed in to change notification settings - Fork 215
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
store Zoe state in durable/virtual objects/collections #4383
Comments
@Chris-Hibbert Assigning to you per the conversation in today's Eng Sync, please put an estimate on it once you have scoped out the task. |
Here's a Catalog of Zoe's storage. It lists 1 WeakSet, 9 WeakStores, and 2 Native Sets. I see at least 3 objects (
|
in #4324 (comment) , @warner writes:
|
Per conversation with @dtribble Chris does not need to prioritize this for Restival. |
Likely people to pick this up if @erights doesnt have the bandwidth to do this in the MN-1 timeframe: @Chris-Hibbert and @turadg |
refs: #4383 The datastore diagram was created in Miro: https://miro.com/app/board/uXjVPR6j4Nc=/?share_link_id=559329933746 The others are .puml rendered to png. These diagrams show the state of Zoe and ZCF as of 2022/10/1. I expect to update them as I finish the conversion to durability. The datastore diagram shows which objects and stores are accessible to Zoe or to ZCF, and which are shared. The sequence diagrams show the order in which the various objects are created, passed between the vats, and when promises are resolved.
…6389) * docs: a set of diagrams on Zoe and Zcf datastores and initialization refs: #4383 The datastore diagram was created in Miro: https://miro.com/app/board/uXjVPR6j4Nc=/?share_link_id=559329933746 The others are .puml rendered to png. These diagrams show the state of Zoe and ZCF as of 2022/10/1. I expect to update them as I finish the conversion to durability. The datastore diagram shows which objects and stores are accessible to Zoe or to ZCF, and which are shared. The sequence diagrams show the order in which the various objects are created, passed between the vats, and when promises are resolved. * docs: updates to Zoe-ZCF dataStores miro diagram Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
…6389) * docs: a set of diagrams on Zoe and Zcf datastores and initialization refs: #4383 The datastore diagram was created in Miro: https://miro.com/app/board/uXjVPR6j4Nc=/?share_link_id=559329933746 The others are .puml rendered to png. These diagrams show the state of Zoe and ZCF as of 2022/10/1. I expect to update them as I finish the conversion to durability. The datastore diagram shows which objects and stores are accessible to Zoe or to ZCF, and which are shared. The sequence diagrams show the order in which the various objects are created, passed between the vats, and when promises are resolved. * docs: updates to Zoe-ZCF dataStores miro diagram Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
What is the Problem Being Solved?
To allow Zoe to maintain low RAM usage despite being involved in every contract, as well as to enable Zoe to be upgraded, we need it to store all long-term state using
makeDurableKind
and virtual/durable collections.I don't know exactly what state Zoe uses. I know there are a lot of Offers and Seats and Invitations and stuff. As a first step, I'm guessing that each of these needs to be converted into a virtual-object Kind, and any collections of them need to be stored in a virtual-collection using something like
makeBigWeakMap
. Performing this translation/porting is probably the bulk of the work.A small step is to then switch to Durable objects/collections instead of merely Virtual ones, for the state that needs to survive an upgrade.
Then a medium step is to record all the collection objects (and handles to the Kinds that must survive) in the #4325 "baggage", so the new Zoe version can retrieve it.
Another large design question is what state ought to survive the upgrade (kept in Durable storage), and what can be discarded (kept in Virtual storage). And what clients will experience during the process. The simplest approach is to just store everything in Durable, but @erights points out that vats and contracts should be more deliberate about their upgrade process.
Description of the Design
Security Considerations
Test Plan
The text was updated successfully, but these errors were encountered: