Hello everyone. I've encountered behavior with the state file that I can't explain. We're working with Amazon RDS, so the example below uses RDS params. I'm almost certain RDS isn't directly to blame. Background: Due to limitations within RDS, in order to create an instance in a different db subnet group in the same regions as the primary host the

replicate_source_db

must be provided in ARN format. e.g.

arn:aws:rds:us-east-1:12345890:db:my-primary-database-1

. However, once the instance is created, RDS stores the

replicate_source_db

as a simple name.

arn:aws:rds:us-east-1:12345890:db:my-primary-database-1

->

my-primary-database-1

. Any further attempts to modify the instance will fail because

arn:aws:rds:us-east-1:12345890:db:my-primary-database-1

!=

my-primary-database-1,

RDS interprets this as an attempt to change the replicate database (which isn't allowed). Our attempt to work around this: 1. Create instance with ARN 2. Manually refresh Pulumi state to capture the short name from RDS 3. Update Pulumi to use short name. 4. Manage instance via Pulumi as usual. The problematic scenario that is what actually happens and brought me here. 1. Create instance with ARN 2. Manually refresh Pulumi state to capture the short name from RDS 3. Update Pulumi to use short name. 4. An attempt to manage the instance (pulumi up) fails with the

arn:aws:rds:us-east-1:12345890:db:my-primary-database-1

!=

my-primary-database-1

mismatch despite that fact that the ARN doesn't exist in the state file or in RDS at the time of execution. 5. The Pulumi state file value goes back to the ARN. 6. Cycle continues Any ideas how this is happening?

This is kind of a lot to consume, maybe a diagram would help? However, I would ask the question of myself, how would I do this if I were using the console and not Pulumi? The answer likely is that you would create some resource, look at it, then use its outputs to create the next. Pulumi supports this using outputs and inputs; https://www.pulumi.com/docs/intro/concepts/inputs-outputs/ . I suspect that careful use of ".apply(....)" would get you what you are after.

some code would be helpful too

Yeah, I realize its a convoluted story.

this feels like a bug in the upstream provider, it shouldn't behave that way

It 100% is a bug. I've been through it with AWS, and they acknowledge it