Error: malformed RPC secret value missing value for "connection"

Error: malformed RPC secret value missing value for "connection"

TL;DR

Your stack state contains secrets that were exported with the wrong passphrase and came back as nulls. The state is corrupted: secrets cannot be decrypted because their values were replaced with null during export. Restore from a backup taken with the correct passphrase, or re-create the affected secrets.

The error

error: malformed RPC secret value missing value for "connection"

Fix it

1. Confirm the corruption: pulumi stack export and search the JSON for "plaintext": "null" on secrets that should have values.

• Success check: you find nulled secrets, proving the export was taken with the wrong passphrase.

1. If you have a backup from before the bad export/import cycle, restore it: pulumi stack import < backup.json with the correct PULUMI_CONFIG_PASSPHRASE set.

• Success check: secrets decrypt and pulumi preview works.

1. If there is no good backup, the original secret values are unrecoverable from state. Rotate/re-create each affected secret (new DB passwords, new tokens) and update the stack config.

• Success check: pulumi up completes and the new secrets are live.

1. Going forward, verify the passphrase before any export: decrypt one known secret first, or add a pre-export check that fails the pipeline on a wrong passphrase.

• Success check: exports either carry real secret values or fail loudly.

When to use this

You hit this at pulumi destroy or pulumi up after a stack export/stack import cycle, especially in automated backup pipelines.

When NOT to use this

Do not use this for a merely unset passphrase. That errors clearly at export time. This is specifically the silent-null corruption from a wrong passphrase.

Compatibility

Pulumi CLI 3.x with the passphrase secrets provider and local/file backends.

Variants

• A panic in parseCheckpointObject on a nil value (helm Release and similar) from the same corruption
• error: malformed RPC secret value missing value for "[other key]" naming whichever secret nulled first

Root cause

stack export --show-secrets with a wrong passphrase exits 0 and writes every secret as JSON null instead of failing. Re-importing encrypts those literal nulls, so the corruption becomes permanent and only surfaces when the provider tries to use a secret.

Edge cases

• The exported JSON looks structurally healthy (valid deployment, correct resources). Only the secret values are wrong.
• Automation API Stack.Export() with a wrong passphrase in env vars has the same silent behavior.