This message was deleted.

export async function getApproximateNumberOfMessages(queueUrl: pulumi.Input<string>): Promise<number> {
    const queueUrlStr = pulumi.output(queueUrl).get()
}

Example aws api function call.

providing a callback in the languages that support it for the lambda relies on function serialziation. So if your function cannot work after being deserialized (because it calls out to an external function) than it will not work. I personally would instead pass my lambda function as a string and I would use

Output.apply(..)

to interpolate the values into the function that you need to, or you could set the values that the function needs as environment variables on the lambda and have the lambda access them

I have been warned to not create resources in apply before.

I am not saying that you should create resources in apply.

Oh. What did you mean? I interpreted that as:

queueUrl.apply(url => {
    const cbFn = new aws.lambda.CallbackFunction(`${name}-callback-fn`, {
        name: `${name}-handler`,
        role: args.role,
        callback: async function (event: aws.cloudwatch.EventRuleEvent) {
            await getApproximateNumberOfMessages(url)
        }
    });
})

Can you link me the reference for

CallbackFunction

? Because all I see here is `Function`: https://www.pulumi.com/docs/reference/pkg/aws/lambda/?iaid=no-experiment Then I could explain better

I'm saying to pass the function as a string and interpolate your value in. Here you can see that

FunctionArgs

takes in an

Archive

in the

code

input. So you could make your archive with a

StringAsset

after interpolating your queue URL. So your code could be:

var code = queueUrl.apply(url => {
    return @"async function (event: aws.cloudwatch.EventRuleEvent) {
        var url = ${url};
        // do work
    }";
});

Using whatever string interpolation looks like. And now your function is an

Output<string>

which can be passed

Oh, I'm using Pulumi's function serialization.

yes I was saying I don't think it will work with function serialization unless you use environment variables.

Makes sense. So then the question is why isn't function serialization async?

think about how function serialization must work - you provide a function to the

callback

parameter. Pulumi is not examining the inside of your function, it can't really do that. All it can do is serialize the function not knowing it's contents. It has no awareness of the fact that your function is calling out to some

Input<T>

or

Output<T>

The function serialization exists purely as a QOL thing in the languages that support it so that you can write your lambda in the same file/language that you are writing your pulumi code