PF defaults not applied

[VenelinMartinov]

What happened?

It seems like for some cases defaults in PF schema are not applied to resource properties.

Quite surprising, happy to be pointed to any errors in the test here.

Found during an attempt at reproing a customer issue with a private PF provider.

Example

#2217

Output of pulumi about

.

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).

[VenelinMartinov]

here are some details from the GRPC calls: change_reason is not mentioned at all:

/pulumirpc.ResourceProvider/Check
{"urn":"urn:pulumi:test::test::prov:index/test:Test::mainRes","olds":{},"news":{"otherProp":"val"},"randomSeed":"JiYdqeul7IEPc4bsh2+Nf751Pg+yyMa/lcUf1A06Obk="}
{"inputs":{"otherProp":"val"}}

/pulumirpc.ResourceProvider/Create
{"urn":"urn:pulumi:test::test::prov:index/test:Test::mainRes","properties":{"otherProp":"val"}}
{"id":"test-id","properties":{"id":"test-id","otherProp":"val"}}

[VenelinMartinov]

@t0yv0 provided some possible context here - PF initially did not support Defaults at all at the time when the PF bridge was initially developed. It relied entirely on PlanModifiers.

Defaults were added later so it is possible something on the TF side changed in the meantime.

[t0yv0]

Still the expectation is that this is handled by PlanResourceChange call to the PF itself, so curious to see where the bug is here.

[VenelinMartinov]

#2225 adds tests for input extraction which is also affected by this issue.

We seem to generate inputs for properties which are using their default values, which is not the intention of the code and is not what the SDKv2 does. We should address as part of this issue.

[t0yv0]

Could you please break out the input extraction interaction with PF Defaults into a separate issue, thanks.