With the new strategy to push diff logic down to the provider and query the backend for old state, I am encountering a case where certain DMS replication instance changes are continuously trying to "update" because AWS schedules the changes during a maintenance window—which can be several days out. Is there a suggested strategy for this kind of scenario so that Pulumi does not continuously try to update the same parameters?

@worried-engineer-33884 can you run

pulumi up

and grab the details view for me and post it here and we can work out what the problem is?

Hi Paul, here's the pertinent piece.

ah, so in this case, if this has been changed in AWS, outside of Pulumi, then you need to

pulumi refresh

it wasn't changed in AWS — i changed it in pulumi — but AWS does not change the replication instance size right away, it is scheduled

ok, so maybe I can't see what the issue is - do you want it to happen straight away?

not necessarily, the issue is that subsequent runs of

pulumi up

continue to try to modify this value because AWS has not performed the change yet

that's kind of expected TBH

what do folks usually do to mark changes that are pending?

so in this specific case, until you know it changes, you can use ignoreChanges

ok

yeah that's the path of most resistance 😄

Or

ignoreChanges

?

ignoreChanges would have to be toggled when we actually do want to change this resource. That doesn't jive too well with our ci/cd workflow, although the changes to a replication instance should be few and far between.