Hi, I'm curious to know how people are handling running pulumi update in an HTTP API . Do you do a fire and forget on the Up operation so calling it without waiting for the result?

I've built an API that returned 202 ACCEPT together with a task ID that allowed the requester to query the status of the Pulumi call. That worked quite well.

@modern-zebra-45309 Are you managing the "task ID" yourself or are you returning the ID that Pulumi gives you when running an update?

I generated a task ID myself and used it to name the job I launched so that I could find it later if a user queries for its state.

If you use Pulumi cloud, couldn’t you just use the ID you’re given to save that extra mapping? Or am I missing some additional benefit here?

We did not use Pulumi Cloud but a self-hosted backend, so that wasn't an option. I didn't spend too much time thinking about which ID to use when I implemented it, I think I just generated a UUID and ran with it. Except when debugging, nobody ever saw this ID.