Not sure if it's just me, or if anyone else has experienced this possible race condition, but I have an IoT custom resource construct like the following in a large stack:
const thing = new cr.AwsCustomResource(this, 'thing', {
onCreate: {
service: 'Iot',
action: 'createThing',
parameters: {
thingName: '001',
thingTypeName: 'thing-type'
},
physicalResourceId: cr.PhysicalResourceId.of(Date.now().toString()),
},
onDelete: {
service: 'Iot',
action: 'deleteThing',
parameters: {
thingName: '001'
},
},
policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE,
}),
});
thing.node.addDependency(thingType);
...that sometimes runs fine following a cdk deploy, and sometimes throws a message like this:
18:14:21 | CREATE_FAILED | Custom::AWS | thing/Resource/Default
Received response status [FAILED] from custom resource. Message returned: User: arn:aws:sts::123456789012:assumed-role/Dev-AWS679xxx-xxx/Dev-AWS679xxx-xxx is not authorized to perform: iot:CreateThing on resource: arn:aws:iot:xxx:xxx:thing/001 because no identity-based policy allows the iot:CreateThing action (RequestId: xxxxx)
It's as if sometimes the policy is not attached to the assumed role in time before the action to create the thing is carried out.
I'll see if I can produce a small stack that can repeat the condition but in the meantime I'm sending this out in case others have experienced this behaviour.
Thanks,
Gary
Hi Nitin, creation of this thing using this construct is just for test purposes. This construct creates the thing. I need to use a custom resource here because I want to add the thing to a thing types (and cannot do this using the cfn L1 construct). I have nothing else trying to do anything in parallel, it's all left to cdk/cfn. Sometimes cdk attaches the policy (see the policy statement in the custom resource) and executes the construct in that order, sometimes it tries to execute the construct before the policy is attached. At least, that's what I think is happening. I'll investigate further