[SOLVED] Hey! I'm switching over from using the Pu...
# automation-api
[SOLVED] Hey! I'm switching over from using the Pulumi CLI to an inline program LocalWorkspace in the Typescript Automation API, and when running
await stack.preview()
, the process exists with an error about leaked promises. Enabling
, I see a bunch (570) of of promises that seem to be related to
in some shape. By hooking into
for the preview function, I noticed that Pulumi thinks I only have 1 resource to create (which is either the stack or an output string of the program), not including the ~30 I'd expect. Is there some additional awaiting I need to do on my inline program or hints at how to debug this further?
My inline program used to just return:
Copy code
return {
  ids: [Output.create("Local Deployment")]
But after changing it to something like:
Copy code
return {
  ids: [Output.create("Local Deployment")],
  ingresses: ingresses.map((ingress) => ingress.urn),
is a
resources), which are a final resource, but not ultimate children (i.e. there are other resources that
don't depend on), the preview doesn't immediately exit, however it does seem like dependencies are being executed out of order
I can try to see if I can share some code related to my pulumi program, but it's quite a learning curve to see what all is happening. I'll try simplifying things down to bare minimums (i.e. just do a single helm release) to see if I can try to figure out root cause
it appears that this is actually 2 separate issues 1. I'm not seeing any resources other than the stack itself marked as going to be created during a preview in the automation api. I can keep only the helm releases and the preview won't throw due to leaked promises, but their are no resources in the preview:
Copy code
Previewing update (dev):
 +  pulumi:pulumi:Stack template-shooter-dev create 
    k8sIds: [
        [0]: "Local Deployment"

    + 1 to create
2. The leaked promises issue only happens when a subset of my resources are enabled in my program. I will need to look into this further, but I'm still not sure about the first issue
I was able to resolve issue #2 by refactoring my services to not be dependent on a premigrated DB with plans to move the migrations external to the pulumi program but still part of the automation script