Make resource functions blocking

[joeduffy]

At the moment, we serialize closures asynchronously. This permits us to capture references to resources whose properties may not have settled yet. Sadly, it suffers from two problems:

• Value captures now happen at indeterminate points in time.
• It is possible to create cycles, which themselves create hangs.

As an example, the Pulumi Framework's crawler example contains this code:

import * as pulumi from "@pulumi/pulumi";

let countDown = new pulumi.Topic<number>("countDown");

countDown.subscribe("watcher", async (num) => {
    console.log(num);
    if (num > 0) {
        await countDown.publish(num - 1);
    }
});

pulumi.timer.interval("heartbeat", {minutes: 5}, async () => {
    await countDown.publish(25);
});

Subtly, the lambda passed to countDown.subscribe closes over countDown itself, and that object internally stores a reference to the aws.lambda.Function that results from serializing the closure. On its face, this should not be possible! The ordering strictly happens as: 1) create the topic, 2) create the function, 3) subscribe. But the use of promises allows us to fast forward in time such that the capture actually depends on the function having been created!

Yikes.

After landing the current Pulumi Fabric overhaul, I'm going to go back and overhaul the overhaul. Most likely, we will do something like this:

1. Hide all waits and resolutions in C++ code so that we can block safely while still processing incoming RPC requests from the host resource monitor (containing property resolutions).
2. Turn Resource into a JavaScript Proxy, so we can hook access to properties, and transparently block by calling into the C++ code. This will eliminate Computed<T>, mapValue, and vastly simplify consumer code. I dare say, it will be gorgeous.

So, good news, we see a path to something awesome. Bad news, it's more work.

[joeduffy]

Bad news: I don't think we can hide Computed<T> and mapValue just yet.

The two ideas we had for doing so entailed first moving blocking into C++ code (which we will do), and then one of the following:

1. Expose a get method that simply returns the T.
2. Atop this same machinery, use JavaScript proxies to hide the get.

Sadly, these both suffer from the fact that we cannot produce a real T for such properties during planning: we simply don't know the values, anything we create would be a poor approximation of the real thing, and it would be dangerous to let code do conditional resource creation using them.

I'm not loving where this lands us. The Computed<T> and whenValue stuff makes me sad anytime I need to use it. I'll keep pondering...

[lukehoban]

What happens if we just return undefined for properties on Resources during planning? It doesn’t feel meaningfully worse than returning a Computed which never resolves.

[joeduffy]

Certainly an option we should keep in the running. I don't love that it would result in a lot of conditional code, but a) experience suggests that this sort of thing is fairly rare, and b) mapValue is conditional anyway, under a different name (and hence could lead to lots of the same pitfalls).

[lukehoban]

mapValue is conditional anyway, under a different name (and hence could lead to lots of the same pitfalls)

Indeed - I noticed in your refactors of code in pulumi-framework that you had to go to some effort to make sure that resource creations didn't happen within the body of a mapValue. In some sense, because the programming model makes it look like you can get an actual value that way, it's easier to try to write the "conditional" code that way accidentally, vs. writing code which is conditional on an undefined result only during planning (you can't try to do much interesting in that branch cause you can't see anything about the value that got you into the branch).

[lukehoban]

I hit another nasty implication of the current model - the types of a captured variable is different on the outside than on the inside.

class Table {
    tableName: pulumi.Computed<string>;
    constructor() {
        let table = new Table();
        this.tableName = table.name;
    }
    async get(query: Object): Promise<any> {
        let awssdk = require("aws-sdk");
        let db = new awssdk.DynamoDB.DocumentClient();
        let o = await db.get({
            TableName: this.tableName,
            Key: query,
        }).promise();
        return o.Item;
    }
}

Here - this.tableName ends up being a Computed<string> on the outside, but a string on the inside.

We only get away with this in our current code because we don't have strong typing around most of the code we write on the inside today - due to the previous requirement to require on the inside instead of use real imports to bring in types.

This makes explaining our outside/inside API another big step harder. I continue to be optimistic we'll find a way to remove this layer of Computed types in the programming model.

[joeduffy]

I think we have an approach to try here. I'll write up and give it another run during M9.

[joeduffy]

Sadly, this is too disruptive to take at this stage. Moving to M10.

[joeduffy]

I've changed the title, since as part of #824 we decided against introducing blocking resource property access. But we did decide that resource functions should offer blocking variants as the default. Moving to M11 for consideration.

[lukehoban]

We've decided not to do this. Current async variants compose well into Output, especially once we address pulumi/pulumi-terraform#204.