Multiple Provider Instances Not Properly Handled During Refresh Operations

[zajda82]

I've discovered a design limitation in Pulumi's refresh workflow when using multiple instances of the same custom provider with different configurations.

During pulumi up, the engine correctly calls Configure for each provider instance with their respective ProviderArgs. However, during pulumi refresh, the engine skips the Configure calls entirely and only invokes Read methods. Since providers are implemented as single processes per package that communicate via gRPC, there's no way for the provider to determine which configuration context applies to each Read operation when multiple differently-configured instances exist.

This creates ambiguity and potential incorrect behavior during refresh operations. The current architecture assumes provider instances maintain their configuration state between operations, but this assumption breaks down when the refresh workflow omits the configuration phase that establishes the proper context for each provider instance.

Am I reading the whole situation wrong or is there better practice for scenarios like this?

To be more specific, I'm developing a Proxmox provider, ProviderArgs specify to which upstream PX cluster the provider should talk to for given resource. That context gets lost for refresh (and arguably for destroy too).

[Frassle]

That's unexpected, Configure should be called for refresh. If you're not seeing that raise an issue with a repro and we'll take a look.

[zajda82]

Got it thank you.

I forgot to mention the refresh is invoked through pulumi automation. So that is also potential culprit.

The fact that the design intent is indeed to call configure will help me with narrowing it down. Will try to put together minimal repro and submit a ticket.