# 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.
2. 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.
3. 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.
4. 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.