Fix 8322

[t0yv0]

Description

Fixes #8322

In other languages like TypeScript, we implement the Output-versioned invokes using Apply. This means in preview, if any arguments are unknown, monitor is not called at all (short-circuit). This was missing in C#, causing breaking previews.

I believe this works but this continues to be a bit awkward at implementation level. Relative to TypeScript and Python, .NET SDK feels a bit lacking in power:

• cannot implement this feature using Apply as it's unclear that the SDK has power to transform inputShape(Args) to Input(Args)

• therefore emulating Apply features indirectly in the serialization related machinery

• decided against detecting unknowns on the native representation (input to the serializer), as doing so involves peeking under lazy Inputs and potentially triggering side-effects, and also it seems a bit tricky to recognize all values correctly

• therefore opted to detecting unknowns AFTER serialization in the serialized form, before it gets projected into protobuf form; this seems to be well defined, but needs eyes as the not supported by type system (object? trees)

Checklist

• I have added tests that prove my fix is effective or that my feature works

• I have updated the CHANGELOG-PENDING file with my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

[t0yv0]

Note: slight reordering here, in that MonitorSupportsResourceReferences call will now go before args.ToDictionaryAsync() await, and before Log.Debug(label); hopefully this is benign.

[t0yv0]

Helper.. Alternatively can go for SerializationResult, or tuples.

[pgavlin]

cannot implement this feature using Apply as it's unclear that the SDK has power to transform inputShape(Args) to Input(Args)

This has come up before, but I want to double-check something for my own understanding: does this mean that without output-shaped functions, .NET users cannot use Apply to achieve the same result b/c the C# type system can't express what we want?

[t0yv0]

This has come up before, but I want to double-check something for my own understanding: does this mean that without output-shaped functions, .NET users cannot use Apply to achieve the same result b/c the C# type system can't express what we want?

The users can always use Apply to emulate fn.Output form by coding the transformation from inputs to Args. That is always possible. However they need to code the transformation in each specific case separately, akin to this:

Tuple(x, y, z).Apply(t =>
{
   GetAmiIds.InvokeAsync(new GetAmiIdsArgs{ X = t.Item1, Y = t.Item2, Z = t.Item3 })
})

What is limited is our generic programming model, not the specific programming model. We're having difficulty here writing code that will work correctly for all possible concrete Args types. We can't easily take the above code and make it abstract over GetAmiIdsArgs.

In TypeScript, the advanced type system takes care of it by being able to type-check the generic programs.

However this is not the only way. In languages with simpler (or no) type systems, reflective programming achieves the same effect.

Basically if we had something like this:

PlainShape<T1,T2>(T1 term) Input<T2> 
PlainShapeReflective(Type t1, Type t2, object term) object // or this

Then we could implement like this:

public Task<GetAmiIdsResult> InvokeAsync(GetAmiIdsArgs args, InvokeOptions? options = null)

public Output<GetAmiIdsResult> Invoke(GetAmiIdsInvokeArgs args, InvokeOptions? options = null)
{
   PlainShape<GetAmiIdsInvokeArgs, GetAmiIdsArgs>(args).Apply(options => InvokeAsync(args, options))
}

Which I think would be cleaner, definitely avoid bugs like the one fixed here. However I think .NET SDK does not yet know how to do something like PlainShape, and it's a bit of work to teach it.

[pgavlin]

The users can always use Apply to emulate fn.Output form by coding the transformation from inputs to Args. That is always possible. However they need to code the transformation in each specific case separately, akin to this:

Okay, this is very helpful. Thanks for clarifying!

[justinvp]

I'm still a bit hesitant about how we handle this in .NET (relying on serialization layer rather than Apply like the other languages), but I understand the reasons.

Some comments/suggestions, but otherwise LGTM.