I'm having issues troubleshooting the deployment of a very complex stack. After a certain point when either refreshing with

--run-program

or when attempting to preview (with or without

--refresh

), my command bails out with:

pulumi:pulumi:Stack (shared-code-artifacts-eks-cb1):
    I1022 15:35:41.061088   82843 log.go:74] Language host launching process: /home/connor/.nvm/versions/node/v24.5.0/bin/node--import tsx --no-deprecation /home/connor/echobox/repos/infrastructure/node_modules/@pulumi/pulumi/cmd/run/index.js --monitor 127.0.0.1:44889 --engine 127.0.0.1:39409 --sync /tmp/pulumi-node-pipes2464160246 --organization organization --project shared-code-artifacts-eks --root-directory /home/connor/echobox/repos/infrastructure/stacks/shared-code-artifacts/eks --stack cb1 --pwd /home/connor/echobox/repos/infrastructure/stacks/shared-code-artifacts/eks --dry-run --parallel 88 index.ts
    The Pulumi runtime detected that 1037 promises were still active
    at the time that the process exited. There are a few ways that this can occur:
      * Not using `await` or `.then` on a Promise returned from a Pulumi API
      * Introducing a cyclic dependency between two Pulumi Resources
      * A bug in the Pulumi Runtime
    Leaving promises active is probably not what you want. If you are unsure about
    why you are seeing this message, re-run your program with the `PULUMI_DEBUG_PROMISE_LEAKS`
    environment variable. The Pulumi runtime will then print out additional
    debug information about the leaked promises.
    I1022 15:36:01.223565   82843 ignore.go:44] Explicitly ignoring and discarding error: sync /dev/stdout: invalid argument
    I1022 15:36:01.223706   82843 ignore.go:44] Explicitly ignoring and discarding error: sync /dev/stderr: invalid argument

    error: an unhandled error occurred: Program exited with non-zero exit code: 1
...

It seems pretty inconsistent in terms of when it crashes, ie not when it's attempting to generate a preview for a specific resource. I did notice that for the resources that it did manage to start generating diffs for, they have an excessively large diff that I wasn't expecting:

[diff: +bottlerocketAmiKeepers,clusterAmi,clusterName,clusterServicesNodegroup,componentOpts,enablePrefixDelegation,enabledClusterLogTy....

which appears to be all of the inputs to that component. Likely related to this change in 3.202.0:

[components/{go,nodejs}] Send component inputs to be saved in state. This brings NodeJS and Go inline with Python behaviour

and indeed, downgrading to 3.201.0 fixes my stacks. These components are very complex and pass around a lot of other components, various unresolved bits of state, etc, so I'm not surprised that change broke them, but even with

--logtostderr --logflow -v=10 2> stderr.log

I wasn't able to get any information out of it to try and debug with (just that it crashed with no related error, followed by the cascading failures due to the leaked promises). My wild stab in the dark is it's something related to how the inputs are being serialized for consumption by the engine. I'll try and work on a reproduction but it's going to take me a bit to untangle things, any other wild stabs in the dark welcome

If you've got unresolved state being passed into components that causes cycles that will now be a problem. But otherwise most things should serialise fine or just get dropped from whats sent to the engine.

I suspect I've got a cycle using deferred outputs, but it's pretty hard to track down where the issue actually is