-
Notifications
You must be signed in to change notification settings - Fork 7
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
Exception besom.internal.DecodingError
in [aws:s3/bucket:Bucket].serverSideEncryptionConfiguration
#148
Comments
Looks like we're getting a NULL: |
Might be related: |
One thing that we could do is to just deserialize that to an empty OutputData.Known but I strongly oppose that. In Scala, we're used to the facts that if something doesn't deserialize, it fails immediately (without throwing) and that Option is propagating None everywhere via combinators. However, if we consistently propagate this null through OutputData.Known with None, the user won't be aware of the issue (because we preserve Option semantics and short-circuit). The None will propagate to another place expecting a value. This null will eventually reach the Pulumi engine, causing issues. The optimal approach is to ignore the situation if the user doesn't interact with it, but notify them immediately if they do, offering a workaround. One such workaround is "don't touch this field." Another potential solution is to provide a The key takeaway is that every such case indicates that the Terraform provider might be misleading about the schema. There are edge cases where a required field isn't truly required and is optional. In my opinion, we should embed logic that logs this to the user's console, even if user doesn't touch that field, allowing them to open a full issue with a description of the event and a generated jsonpatch rule to add to the patch library. If the user touches that field - we have to stop execution with an error - there is nothing sane we can do without completely subverting the typesystem. The codegen should check during generation whether the patch indicates that the field has a different real semantics. This would allow us to actively type-fix schemas instead of pretending everything is fine and "tolerating" nulls in non-nullable fields. The generated documentation for the field says it's required and non-nullable, but you might get a null - laughable. |
Solved by #163 |
We need a new issue to track all of the borked fields as reports arrive though. |
I've added a tracking issue as requested: #179 |
The stack trace:
Relevant schema:
The case class:
Raw wire (
PULUMI_ENABLE_TRACE_LOGGING_TO_FILE
):The text was updated successfully, but these errors were encountered: