Upgraded stateShape may be incompatible with existing state
#7337
Comments
|
@erights suggests that the Exo class definition could take an
This would require keeping track of which This also implies that |
|
Since we can test whether two In order to compress a given instance by the Only durable kinds need support either segmentation or |
|
Also suggest that similar schema upgrade concerns will apply to change of Similarly, only durable stores need support for such schema change. Virtual-non-durable stores are single incarnation anyway, so the issue does not arise. |
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
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
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
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
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
|
In #7407 I wrote up this upgrade process with a bit more detail, specifically for durable Kinds (perhaps we should merge the tickets?). In doing so, I came to the conclusion that we really should use a distinct version number of some kind, instead of relying only on |
|
I think these are not entirely mutually exclusive. If a user provides an existing version number, we need to check that the shape is the same as the one that was recorded for that version. But besides that, I agree we would no longer need to compare the stateShape before and after to decide if it's different, and create a new segment. Only the user provided version would create new segments. |
|
We landed the " Let's define this ticket to mean "accept different If we implement #7407 upgrades first, then we don't need to implement this ticket:
|
|
Specific need: adding/removing/changing an annotation-only Remotable/Promise matcher label—cf. endojs/endo#1933 (comment) |
|
I'll agree that #7407 is the likely approach (merely relaxing the schema is harder to measure implement, and would make compression more difficult), and that we can close this now. |
Describe the bug
An ExoClass accept a
stateShapeargument that validates the state at get/set (including init).If a new incarnation provides a
stateShapethat is incompatible with the state created in previous incarnations, the existing instances will fail when they try to read their state.Expected behavior
Rewiring the kinds with
stateShapechecks should enforce that the newstateShapeis "compatible" with the previous one, aka that all existing states pass the newstateShapecheck. If incompatible, redefining the ExoClass should fail.I'm not sure if removing a stateShape is possible, but if it is, it should be the equivalent to setting the new
stateShapetoM.any(), aka any further restriction is impossible.The text was updated successfully, but these errors were encountered: