-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: sns topic creation should not be idempotent #3798
Conversation
This is a re-roll of #3235. See [this comment](#3288 (comment)) for why we are re-rolling this. closes #3288 Co-authored-by: VenelinMartinov <[email protected]>
Does the PR have any schema changes?Does the PR have any schema changes?Found 33 breaking changes: Resources
Functions
Types
Maintainer note: consult the runbook for dealing with any breaking changes. |
Is README.md missing any configuration options?
Please add a description for each of these options to |
+ return fmt.Sprintf("arn:aws:sns:%s:%s:%s", region, account, snsTopicName) | ||
+} | ||
+ | ||
+var snsGlobalMutex sync.Mutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I've approved this before but is this is going to be pretty nasty for programs that create 1000 topics this mutex will create a global chokepoint if there wasn't one already, so they will be literally created one at a time?
Do we just need locks for a particular topic? in that case maybe we could have a sync.Map of murexes indexed by topic ARN here so as not to conflict globally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@t0yv0 I've updated this so that the lock is based on the topic arn. I think we only care to prevent race conditions if the topics have the same name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good but recommend landing the upstream upgrade first as patch merging is a mess.
Hey folks, I might have missed a discussion here - why'd you opt to close this? |
I messed up trying to rebase the patches from master so I just recreated it #3809 |
This is a re-roll of #3235.
See this comment for why we are re-rolling this.
closes #3288
Co-authored-by: VenelinMartinov [email protected]