Implement support for SNS Topics #354
Conversation
zackproser
requested review from
yorinasub17,
rhoboat and
denis256
as code owners
| if len(identifiers) > 100 { | ||
| logging.Logger.Errorf("Nuking too many SNS Topics (100): halting to avoid hitting AWS API rate limiting") | ||
| return TooManySNSTopicsErr{} | ||
| } | ||
|
|
There was a problem hiding this comment.
Do we know that 100 is the limit? Should we detect rate limiting and respond to that, or is that overkill?
There was a problem hiding this comment.
We don't know for sure, but this is the pattern for proactively trying to avoid rate limiting that I find us carrying throughout the resources. It would be nice if we had some intelligent logic to respond to rate limiting, but I'd need to think about the cleanest way to do that.
| if err == nil { | ||
| logging.Logger.Infof("[OK] Deleted SNS Topic (arn=%s) in region: %s", aws.StringValue(topicArn), region) | ||
| } else { | ||
| logging.Logger.Errorf("[Failed] Error deleting SNS Topic (arn=%s) in %s", aws.StringValue(topicArn), region) |
There was a problem hiding this comment.
If we're rate limited, is this where execution will end up? I think this is fine. In the worst case we'll have to retry the delete.
There was a problem hiding this comment.
Yep, that or any other unhandled cause for an error state should end up here.
zackproser
force-pushed
the
feature/sns-topics
branch
from
8809e8e to
bf21784
Compare
|
Thanks for reviews! Going to merge this in now. |
Description
Fixes #173 .
TODOs
Read the Gruntwork contribution guidelines.
Release Notes (draft)
Implement support for inspecting and nuking SNS Topics.
Migration Guide