🧱 Pulumi Error: 'resource registration timed out' — RegisterResource Hang Fix

Exact Error Message

error: resource registration for urn:pulumi:dev::my-app::aws:s3/bucket:Bucket::data timed out
    while waiting for the engine to complete the operation

error: update failed
Diagnostics:
  pulumi:pulumi:Stack (my-app-dev):
    error: one or more resource registrations did not complete within the timeout

You may also see a run that simply stops printing progress after Diagnostics: and eventually errors with context deadline exceeded from the resource monitor. Both are symptoms of a RegisterResource call that never returned.

What It Means

When your Pulumi program declares a resource, the language host sends a RegisterResource RPC to the deployment engine and waits for the engine (and the underlying provider) to create, read, or update it. “Resource registration timed out” means that round trip never finished. Either your program stopped feeding the engine — usually an unawaited promise or a hung apply callback — or the provider is blocked on a slow, retrying, or deadlocked cloud API call.

The engine cannot finish an update until every registered resource resolves, so one stuck registration hangs the whole pulumi up. This is a control-flow or connectivity problem, not a syntax error.

Common Causes

• An async resource-construction path where a Promise (or Go context) is never awaited, so the program exits or idles before the resource is fully registered.
• Logic inside an apply() / Output.apply callback that blocks, throws asynchronously, or itself awaits something that never resolves.
• The provider is stuck retrying a throttled or unreachable cloud endpoint (expired credentials, VPC endpoint down, rate limiting).
• A dynamic provider or ComponentResource whose constructor performs blocking I/O without returning.
• Network egress to the Pulumi Service or provider API is blocked mid-run, so the RPC stalls rather than fails fast.
• A very large resource graph hitting a genuinely slow create (for example a database or managed cluster) that exceeds an internal wait.

Diagnostic Commands

Re-run with full engine and provider tracing to see which resource stalls:

pulumi up --logtostderr --logflow -v=9 2>pulumi-debug.log

Identify the last resource the engine touched before the hang:

grep -E "RegisterResource|Create|Update" pulumi-debug.log | tail -n 40

Confirm the stuck resource in stack state:

pulumi stack --show-urns

Check that provider credentials and endpoints are actually reachable (AWS example):

aws sts get-caller-identity

For Node programs, look for unhandled promise warnings that often accompany the hang:

node --trace-warnings $(command -v pulumi) up 2>&1 | grep -i promise

Step-by-Step Resolution

1. Await every asynchronous resource call. In TypeScript, resources are created eagerly, but any Promise you build in the program must be returned or awaited so the process stays alive until registration completes:

// Bad: fire-and-forget, program may idle before registration finishes
async function main() {
    getData().then(v => new aws.s3.Bucket("data", { tags: { v } }));
}
// Good: await, then declare
async function main() {
    const v = await getData();
    return new aws.s3.Bucket("data", { tags: { v } });
}
export const done = main();

2. Never block inside apply. Keep Output.apply callbacks pure and fast; move slow I/O outside the resource graph:

// Avoid awaiting a hanging call inside apply
bucket.id.apply(id => callSlowApi(id)); // if callSlowApi hangs, registration hangs

3. Fail fast on provider timeouts by setting a customTimeouts so a slow create errors instead of hanging indefinitely:

new aws.rds.Instance("db", { /* ... */ }, {
    customTimeouts: { create: "20m", update: "20m", delete: "20m" },
});

4. Verify connectivity and credentials to both the provider API and (for the managed backend) the Pulumi Service. Rotate expired tokens with pulumi login and confirm aws sts get-caller-identity (or the equivalent) returns quickly.

5. Isolate the offending resource with --target to prove which registration stalls, then fix its construction logic:

pulumi up --target 'urn:pulumi:dev::my-app::aws:s3/bucket:Bucket::data'

6. Re-run and confirm the update completes without the timeout:

pulumi up

If you are unsure whether a callback is safe to run inside apply, describe the code to an assistant using a prompt from the Pulumi prompt library to get a second read on the async flow.

Prevention

• Treat apply callbacks as synchronous, side-effect-free transformations; do all slow work before the resource graph.
• Always await or return promises in async programs and export the top-level promise so the host waits for it.
• Set explicit customTimeouts on resources known to be slow so a stuck create surfaces as a clean error.
• Add unhandled-rejection logging in Node (process.on('unhandledRejection', ...)) to catch swallowed async errors early.
• Run provider connectivity checks in CI before pulumi up so credential/endpoint problems fail fast.

Related Errors

• error: resource monitor shut down while sending resource registration — the language host died mid-registration rather than timing out.
• Error reading from server: EOF — the connection to the engine/service dropped.
• transport is closing / rpc error: code = Unavailable — the plugin RPC channel closed unexpectedly.
• context deadline exceeded from a provider — the underlying cloud API call itself timed out.

Frequently Asked Questions

Why does my program hang only sometimes? Intermittent hangs usually mean a race with an unawaited promise or a provider retrying a throttled API — timing determines whether the RPC returns before the internal wait expires.

Can I just raise the timeout to fix it? Raising customTimeouts helps only when a create is genuinely slow; if the cause is an unawaited promise or blocked apply, a longer timeout just delays the same failure.

Is this a Pulumi bug or my code? Almost always it is program control flow (unawaited async work or blocking inside apply) or provider connectivity, not the Pulumi engine itself.

How do I see which resource is stuck? Run pulumi up --logtostderr --logflow -v=9 and read the last RegisterResource/Create line in the log; that URN is the one that never completed. For more debugging patterns, see the Pulumi guides.