Hi, I just created a new environment (test2) for my app, and now I’m trying to deploy a service to that environment but it fails.

Just for context, I’m attempting to use a monorepo setup:

• My apps (services) are in /apps/
• My copilot manifests etc are in /infrastructure/copilot/
• I always run copilot from /infrastructure/
• Each manifest has an image property that points to

At the moment the number of tasks able to be launched for a given scenario is 10 do to restriction with ECS. A workaround that creates multiple ECS instances for a given scenario based on the number of tasks requested should be added.

Errors are retried immediately and forever. Would be good to enter a truncated exponential backoff loop or similar. A full jitter algorithm is available and in use by the AWS client. We should make sure failed messages are retried after an interval derived from that.

https://github.com/Blissfully/sqs-lambda-bridge/blob/eba837a7b080092ed44706aa53125c33aa8da1be/src/aws.js#L4-L15

AWS orbs that authenticate with secrets such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY typically use the type env_var_name for commands and jobs accepting those parameters. This orb uses the string type. If a user is importing both the ecr orb and this orb together (which is quite typical) the inconsistency can be confusing and lead to frustrating configuration errors. Once a user dis