This message was deleted.

If you add a dependsOn from the policyAttachments to the lambdas, would that require that Pulumi deletes the attachments first?

not sure, The lambdas are defined through awsx.API routes and all that was defined for them were path, method, and eventHandler. Doesn't seem like a route defintion accepts dependsOn And seems kind of chicken / egg to declare the .API depends on the lambdas it's supposed to be declaring.

dependsOn is in the

opt

parameter, not the

args

.

hmm.

deleting urn:pulumi:company1::myCompany-pulumi::aws:apigateway:x:API$aws:iam/policy:Policy::hello-only-imported927f543c-LambdaFullAccess: 1 error occurred:
        * Error deleting IAM policy arn:aws:iam::863178862591:policy/hello-only-imported927f543c-LambdaFullAccess-e34ce24: DeleteConflict: Cannot delete a policy attached to entities.
        status code: 409, request id: 80183c5f-327d-42d6-9c27-1ab4b499fab9

Ah, you're using API gateway from awsx? Then I'd say this is a bug.. if it's creating things with a clear deletion order that awsx should know about, but aws can't know about, then it should add the

dependsOn

opt for you...

right yea. Okay i'll get it working manually and then see if i can get it boiled down to be reproducible.

I see several issues about this sort of thing in AWSX, but relating to VPCs and subnets...

yea i'm still very new to pulumi but so far awsx has caused some headaches. It seems to work fine on fresh deployments but once i start trying to shuffle what region the entire gateway is in or even just shuffling around the lambdas and what routes they're on it starts getting shaky.

That's pretty much my experience too. Great time-saver when getting started, but eventually you'll have to migrate away from it once you need to do complicated stuff.

gotcha, well hopefully i can get it repeatable and get an issue opened, thanks for the help!

Or maybe a race condition? Pulumi may have deleted something in parallel but without a

dependsOn

. If there had been a

dependsOn

, it would have deleted them sequentially (= correctly).

Right, seems likely. From what i could tell everything it wanted to delete was there and i had to remove it manually and then use state to destroy those resources until it was able to remove the rest.

Well if there was a race condition and the "blocking" resource got deleted anyway, then simply running the same command should finish the job safely...

could also be the difference of not giving .API any opts at all and then trying to force it to move regions by handing it an opts with a provider in a different region.

that's what i'm going to do to see if i can reproduce the issue

hmm ¯\_(ツ)_/¯

lol agreed