Add support for Call

[iwahbe]

This PR adds support for the Call gRPC method at the top level Provider struct.

[t0yv0]

What's the test plan here?

[iwahbe]

What's the test plan here?

I'm trying to determine the correct behavior before adding tests. We will definitely need tests before merging.

[iwahbe]

Tests have been added. I think this is ready to merge.

[t0yv0]

Is this needed even when the provider has first-class outputs in Return, where this approximation can be un-abmiguously computed? Probably no harm in including but I thought maybe engine does this?

[iwahbe]

I'm not sure, but there is no documentation saying that it isn't necessary.

It seems like it is not necessary in modern Pulumi:

https://github.com/pulumi/pulumi/blob/cbfea508e7b2a4f1dd0985cefbeda3a6e891f7f9/pkg/resource/deploy/source_eval.go#L1140-L1142

I'm hesitant to assume that it is never necessary.

[iwahbe]

I opened pulumi/pulumi#17113 to pin down an answer here.

[t0yv0]

Nit: I would rename the PR to drop "at the provider level", looks like this introduces support for the Call gRPC method which is great.

[t0yv0]

One important question is instance lifetime. When a client issues a series of Call methods against a resource with the same URN, is there a possibility for the provider author to rely on the retention of in-memory instance state across the series of calls?

const c = new Counter()
c.increment()
c.increment()
export const n = c.curentValue /// 2

To achieve the above UX would it be possible for the implementation to be equally simple?

[t0yv0]

Code looking good but I had a few non-blocking questions. I also would suggest considering an E2E test involving the real Pulumi CLI and a sample program, at least one of those for the happy path.

[t0yv0]

Corner cases to think of (perhaps handled already in this codebase).

1. Does Call issue during preview. If so how are unknowns handled?

2. If there are schema-level or first-class secrets, does the implementation guarantee reasonable secret wrapping.

[iwahbe]

Corner cases to think of (perhaps handled already in this codebase).

1. Does Call issue during preview. If so how are unknowns handled?
2. If there are schema-level or first-class secrets, does the implementation guarantee reasonable secret wrapping.

1. I believe that it does. Call is supposed to result in a Pulumi program running (with pulumi.Output), so it unknowns should just flow through.
2. Not at all. This implementation just brings Call support into the base level of the library. Semantic guarentees like (if secret in the schema, then secret on the wire) are handled at a higher level (Call is not hooked up to infer).

[iwahbe]

One important question is instance lifetime. When a client issues a series of Call methods against a resource with the same URN, is there a possibility for the provider author to rely on the retention of in-memory instance state across the series of calls?

const c = new Counter()
c.increment()
c.increment()
export const n = c.curentValue /// 2

To achieve the above UX would it be possible for the implementation to be equally simple?

I believe that this is possible now, though I would discourage relying on it. AFAIK the protocol does not make any guarantees about number of provider instances, or the order of calls. In theory, both c.increment()s could be called in parallel.

[pulumi-bot]

This PR has been shipped in release v0.22.0.

[pulumi-bot]

This PR has been shipped in release v0.23.0.