No standoff on queue errors

[eurostar-fennec-cooper]

Describe the bug
If the queue does not actually exist, this error:
{"name":"SQSError","code":"AWS.SimpleQueueService.NonExistentQueue","statusCode":404,"retryable":false,"time":"2021-09-01T12:53:04.983Z"}
Is endless generated with no wait time in between retries. Not critical, but if errors are logged, it spams the logs/consumes a lot of resources attempting to retry immediately.

To Reproduce
Steps to reproduce the behaviour:

1. Construct a Consumer for a queue that does not exist
2. Add an event handler to the queue that logs the "error" event
3. Run code, error event handler is called endlessly filling up the logs and increasing CPU consumption by a huge margin

Expected behaviour
A clear and concise description of what you expected to happen.

There should be a standoff in between retries for any error involving the queue whatsoever.

screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here, such as specific device information.

[Jobet-delima]

Hello, Wondering if you're able to handle this somehow? Also seeing endless logging on an error such as when AWS region or queue URL is wrong. I reckon these are set-up errors that should be dealt with to get things working initially, but I'm worried that something changes in the set-up later on, then these error generation would consume log space and CPU.

This may be behaviour for anything that triggers the "error" event.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[nicholasgriffintn]

So AWS returns the code AWS.SimpleQueueService.NonExistentQueue for this error, so we could definitely make a change the isConnectionError function to also listen for this code, if this is true, then polling will not occur again until the value of authenticationErrorTimeout, so it will trigger again, but not until that timeout, which is 10s by default.

To note: We would still want to ping again as it's possible that the queue just isn't ready yet, such as in local testing or the service was launched before the queue was created.