The second part of the PR applies throttling to

DescribeJobDefinitions

in addition to the throttling applied to

DescribeJobs

. Bearing our systems’s setup in mind, savin’s explanation for this is that

we check if the job definition exists or not for every task and a step could map to multiple tasks (in case of a for-each)

and an alternative solution could be:

to ensure that we register the job definition only per step

On top of that, I propose a third solution which would be (following the design pattern I’ve introduced in this PR (

@Throttle()

and

with manage_client_error()

) one could decorate the batch client itself with a throttler to guard against large numbers of edge-case AWS limits like this arising from other parts of the boto3 API

Ensuring

DescribeJobDefinitions

gets called only once per step - like it happens for step functions should significantly reduce the number of

DescribeJobDefinitions

. Compared to throttling this call as well, reducing the absolute number of calls will provide better reliability guarantees. I can open a PR if this approach seems reasonable.

seems reasonable to me - it would be great if you could open a PR for that, thanks for taking a look 🙂

Great! I will open a PR in the next few days.