Hi everyone! Using the pulumi automation API to run some tests - but up'ping one of my stacks. I often get the following errors: + azure-native:authorization:RoleAssignment role-assignment-IntTwkzlRG-acr-push creating error: autorest/azure: Service returned an error. Status=400 Code="PrincipalNotFound" Message="Principal a284d038836544ce8b186690db150566 does not exist in the directory 2b1d14a0-2c64-4c0f-ae25-b3195783fced. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group. Now, I'm aware it is telling me to wait... is there a reasonable way to achieve this magically/automatically with Pulumi? Thank you!

What kind of principal is this? I have an role assignment that I’ve set up and it works great with no issues

It's a service principal used for an Azure DevOps Service Connection. I ended up creating a custom resource, that runs ... wait for it (close your eyes) a pulumi command that sleeps for 120 seconds. Just as a test. Then I subsequently started injecting this "stupid wait" as a dependency in the RoleAssignments.... honestly makes me want to barf, but I need this to be reliable.

im not 100% sure about Pulumi since im pretty new to the stack, but things like terraform usually build a dependency graph based on things properties that reference resources that should have been previously created. in theory if you’re referencing a PrincipalId for a resource that you’re managing via Pulumi, it should wait until that’s been completely created and then attempt to create the dependent resource.

Yep - that is true. I have been using that - but making use of the input/output automatic dependency functionality. E.g. I used Output<string> (the principal ID) as an input into the RoleAssignment - which should create that dependency. Even then, Azure sometimes fails. The failure is well documented though - its basically this from what I understand: a new AD group is created in a single region, then gets replicated. While replication is still taking place, the request to perform a RoleAssignment hits a different region which has not yet received the new AD group - boom. So, that's why I was chasing the terrible idea of injecting a silly time span into the whole thing - solely to hopefully allow this replication to occur.

interesting - ill keep an eye out for that as well. thanks for the heads up