You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the provider handles writeOnly & createOnly properties in a special way. WriteOnly properties always need to be sent as an add whereas properties marked as createOnly need to be omitted from the patch completely.
The patch calculation wrongly assumes that writeOnly & createOnly properties exist only on the root level of the resource, but in reality they can be nested.
This has the effect that nested writeOnly & createOnly properties are ignored.
Nested writeOnly properties that are ignored don't necessarily lead to a bug. This depends on how the underlying AWS services handle updates. If they expect all properties to be supplied, the request will fail, but if they only expect the changed properties it's fine.
If nested createOnly properties overlap overlap with a root level writeOnly properties it will lead to errors though because those createOnly properties mustn't be included in the request.
An example of this is the resource aws-native:pipes:Pipe. The sourceParameters parameter is marked as writeOnly and some of the nested properties like sourceParameters/ManagedStreamingKafkaParameters/TopicName are marked as createOnly.
The correct patch would include all properties of sourceParameters except sourceParameters/ManagedStreamingKafkaParameters/TopicName because it's marked as createOnly. But right now the complete sourceParameters are sent, causing API failures.
Affected resources
A search through the CFN schemas reveals 49 resources that have nested writeOnly properties:
for file in *.json; do
if jq -e '.writeOnlyProperties? // [] | any(.[]; (gsub("[^/]"; "") | length) > 2)' "$file" > /dev/null; then
echo "$file"
fi
done | wc -l
49
And there's 2 that have nested createOnly properties that overlap with root level writeOnly properties:
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered:
What happened?
Right now the provider handles writeOnly & createOnly properties in a special way. WriteOnly properties always need to be sent as an
add
whereas properties marked as createOnly need to be omitted from the patch completely.The patch calculation wrongly assumes that writeOnly & createOnly properties exist only on the root level of the resource, but in reality they can be nested.
This has the effect that nested writeOnly & createOnly properties are ignored.
Nested writeOnly properties that are ignored don't necessarily lead to a bug. This depends on how the underlying AWS services handle updates. If they expect all properties to be supplied, the request will fail, but if they only expect the changed properties it's fine.
If nested createOnly properties overlap overlap with a root level writeOnly properties it will lead to errors though because those createOnly properties mustn't be included in the request.
An example of this is the resource
aws-native:pipes:Pipe
. ThesourceParameters
parameter is marked as writeOnly and some of the nested properties likesourceParameters/ManagedStreamingKafkaParameters/TopicName
are marked as createOnly.The correct patch would include all properties of
sourceParameters
exceptsourceParameters/ManagedStreamingKafkaParameters/TopicName
because it's marked as createOnly. But right now the completesourceParameters
are sent, causing API failures.Affected resources
A search through the CFN schemas reveals 49 resources that have nested writeOnly properties:
And there's 2 that have nested createOnly properties that overlap with root level writeOnly properties:
AWS::Pipes::Pipe
AWS::RefactorSpaces::Route
Example
See #1721 for repro
Output of
pulumi about
n/a
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: