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]

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]

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.