-
Notifications
You must be signed in to change notification settings - Fork 212
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
record durable-kind stateShape, with refcounts #7365
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partial review for now.
so future incarnations can compare the old one against newer ones when they
re-define the Kind.
To clarify, this compatibility check is not part of this PR? Any reason not to enforce an exact match for now? One way to do that would be to compare the serialized cap data of the before and after shape, and assert they're equal.
vrm.updateReferenceCounts(oldStateShapeSlots, newStateShapeSlots); | ||
durableKindDescriptor.stateShapeCapData = stateShapeCapData; // replace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should optimize the case where we don't have (and didn't have) a stateShape by omitting it from the descriptor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, and I did that for virtual collections' keyShape
/valueShape
, but Kinds are low-cardinality, so we're not saving very much space.
Correct, this doesn't assert that an upgraded |
04e4d1b
to
0a3c0ef
Compare
5fa3b10
to
ead0df2
Compare
c80bdb8
to
a9b2fad
Compare
ead0df2
to
7837a4f
Compare
a9b2fad
to
db996d0
Compare
7837a4f
to
a38e312
Compare
db996d0
to
5af1b31
Compare
a38e312
to
9252647
Compare
@mhofman I've added the must-be-the-same check, please re-review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides the nit on the encoding assumptions made by the comparison, LGTM.
9252647
to
c617f76
Compare
c617f76
to
ad2c0a2
Compare
This passed Chain Deployment Test but it's not merging because of the new required checks. Those won't be run until #7393 is in master, but that's queued up behind this. So I'm adding bypass to get this into master and drain the queue. |
Oh, unfortunately now that the checks are required nothing can merge without the tests being run. So we need to put this back into the queue after the CI change PR. @Mergifyio unqueue |
ad2c0a2
to
5d36843
Compare
5d36843
to
65a871f
Compare
test-vats (16.x) was cancelled due to timeout, so I took the liberty of hitting the CI "rerun failed jobs" button. |
65a871f
to
3b42405
Compare
When a vat upgrade provides a new definition for a pre-existing durable Kind, it can supply a `stateShape` option that might not be compatible with one established by the previous incarnation. The long-term issue is how to manage "schema upgrades", as the permissible/desired shape of the virtual-object `state` data changes over versions. For now, our main concern is that userspace doesn't create a situation where reading a `state` property causes an error, because the new `stateShape` rejects values that were recorded by an earlier version. The short-term fix is to insist that each new incarnation defines the Kind with exactly the same `stateShape` as its predecessor. This check is performed by comparing the serialized/marshalled capdata of `stateShape` against that of the earlier version, which is convenient but overly strict (e.g. the properties must be defined in the same order). If violated, the new-version `buildRootObject` will throw an error as it calls `defineDurableKind`. refs #7337
This implementation assumes that both old and new stateShapes were marshalled with the same version (e.g. smallcaps vs pre-smallcaps). If we introduce a third format in the future, we should change insistSameCapData to re-serialize the old data into the current format before attempting to compare the capdata bodies.
3b42405
to
bf67ea9
Compare
Save a serialized copy of the Kind's
stateShape
option, so futureincarnations can compare the old one against newer ones when they
re-define the Kind. Increment refcounts on any objects included in the
shape. Forbid the use of non-durable objects in the shape.
closes #7338
refs #7337