Kernel silently ignores additional properties when deserializing structs #822
Assignees
Labels
bug
This issue is a bug.
effort/large
Large work item – several weeks of effort
module/kernel
Issues affecting the `jsii-kernel` module
Comments
RomainMuller
added
bug
RomainMuller
added
module/kernel
|
Capturing context from aws/aws-cdk#3917, this is impacting the use of L1 constructs from the SAM module. |
|
An "easy" solution here involves throwing an error when encountering an un-modeled property instead of ignoring it; however this means the various runtimes may not serialize additional properties; which may require adding code there to this effect. Alternatively, we could deserialize unknown properties as if they were present & typed |
|
Another instance of this in Java identified from a customer report - aws/aws-cdk#2013 |
RomainMuller
added
effort/large
RomainMuller
added a commit
that referenced
this issue
Oct 30, 2019
When deserializing structures in a Union context, the Kernel used to try
options in an arbitrary order (actually - the declaration order which
often is alphanumerically sorted). In addition, it would ignore any
additional property encountered silently.
In cases where several of the union's possibilities had overlapping
required properties, the first attempted option would succeed, even if a
subsequent option would have consumed more properties. A pathologic case
of this is when the first candidate is a type with only optional
properties; as such a type would *always* successfully deserialize
anything, possibly ignoring all properties.
In order to address this, the `structs` can now be passed into the
Kernel by wrapping the object in a decorator box:
```js
{
"$jsii.struct": {
"fqn": "fully.qualified.struct.TypeName",
"data": {
/* the actual data included in the struct instance */
}
}
}
```
This enables "native" languages to correctly communicate the intended
type to the Kernel, so it can make an appropriate deserialization
decision.
The encoding of structs from the Kernel to "native" languages has not
changed: those are still passed by-reference in order to maximize the
compatibility; and to avoid undeterministic behavior in case where union
of structs are returned.
Fixes #822
Fixes aws/aws-cdk#3917
RomainMuller
added a commit
that referenced
this issue
Oct 30, 2019
When deserializing structures in a Union context, the Kernel used to try
options in an arbitrary order (actually - the declaration order which
often is alphanumerically sorted). In addition, it would ignore any
additional property encountered silently.
In cases where several of the union's possibilities had overlapping
required properties, the first attempted option would succeed, even if a
subsequent option would have consumed more properties. A pathologic case
of this is when the first candidate is a type with only optional
properties; as such a type would *always* successfully deserialize
anything, possibly ignoring all properties.
In order to address this, the `structs` can now be passed into the
Kernel by wrapping the object in a decorator box:
```js
{
"$jsii.struct": {
"fqn": "fully.qualified.struct.TypeName",
"data": {
/* the actual data included in the struct instance */
}
}
}
```
This enables "native" languages to correctly communicate the intended
type to the Kernel, so it can make an appropriate deserialization
decision.
The encoding of structs from the Kernel to "native" languages has not
changed: those are still passed by-reference in order to maximize the
compatibility; and to avoid undeterministic behavior in case where union
of structs are returned.
Fixes #822
Fixes aws/aws-cdk#3917
Fixes aws/aws-cdk#2013
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Bug Report
Affected Languages
TypeScriptorJavascriptPythonJavaC#,F#, ...)General Information
0.17.0What is the problem?
The kernel struct deserialization silently ignores any properties that the type does not declare. When deserializing type unions where the first candidate has no required property, this means serialization will ignore everything and succeed (resulting in an empty object), instead of attempting the next candidate type.
This is the root cause of aws/aws-cdk#3917
The text was updated successfully, but these errors were encountered: