Pulumi Provider Plugin Version Mismatch During Preview

Scenario

A Pulumi stack was created with a provider plugin aws‑provider@1.2.0. The stack’s checkpoint records the provider reference, but the current CLI and language SDK are bundled with aws‑provider@2.0.0. No 1.2.0 plugin is available locally, and the network may be unreachable.

Uncertainty

When running pulumi preview Pulumi must decide whether to:

• Download a compatible plugin that satisfies the program’s provider constraints.
• Fail early because the required plugin is missing or incompatible.
• Proceed with a best‑effort diff using the available plugin, potentially misrepresenting the true state.

The chosen path affects whether resources are reported as updates, replacements, or no‑ops.

Questions

1. Does Pulumi automatically attempt to acquire a provider plugin that matches the stack’s recorded reference when the exact version is absent?
2. If acquisition fails or the plugin is incompatible, does the engine fail closed or continue with a best‑effort diff?
3. What pre‑preview checks should an operator perform to confirm provider‑plugin compatibility and avoid unintended resource changes?