Skip to content
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): create subscription object under subscriber #1645

Merged
merged 6 commits into from
Feb 6, 2019

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Jan 31, 2019

Create the SNS Subscription object under the subscriber
instead of the subscribee, avoiding cyclic stack dependencies
if those objects would be in different stacks.

Fixes #1643, fixes #1534.


Pull Request Checklist

  • Testing
    • Unit test added
    • CLI change?: coordinate update of integration tests with team
    • cdk-init template change?: coordinated update of integration tests with team
  • Docs
    • jsdocs: All public APIs documented
    • README: README and/or documentation topic updated
  • Title and Description
    • Change type: title prefixed with fix, feat will appear in changelog
    • Title: use lower-case and doesn't end with a period
    • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
    • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
  • Sensitive Modules (requires 2 PR approvers)
    • IAM Policy Document (in @aws-cdk/aws-iam)
    • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
    • Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

Create the SNS Subscription object under the subscriber
instead of the subscribee, avoiding cyclic stack dependencies
if those objects would be in different stacks.

Fixes #1643, fixes #1534.
@rix0rrr rix0rrr requested a review from a team as a code owner January 31, 2019 13:43
@eladb
Copy link
Contributor

eladb commented Feb 1, 2019

Make sure to indicate this is a breaking change since it will cause resource replacement

@@ -169,14 +169,18 @@ export abstract class TopicBase extends cdk.Construct implements ITopic {
* @param queue The target queue
*/
public subscribeQueue(queue: sqs.IQueue): Subscription {
const subscriptionName = queue.node.id + 'Subscription';
if (this.node.tryFindChild(subscriptionName)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make IQueue extend IConstruct

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, but scope: Construct and not scope: IConstruct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Damn, right. I feel this is going to bite us at some point. But I really don't want people to need to specify scope: IConstruct in the initializer...

throw new Error(`A subscription between the topic ${this.node.id} and the queue ${queue.node.id} already exists`);
}

// we use the queue name as the subscription's. there's no meaning to subscribing
// the same queue twice on the same topic.
const sub = new Subscription(this, subscriptionName, {
const sub = new Subscription(queue, subscriptionName, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Explain why you use the queue as a scope

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Feb 1, 2019

Make sure to indicate this is a breaking change since it will cause resource replacement

Don't think this is necessarily true. It's not breaking at the API level, and the replacement will happen creation-first, then deletion, so should be interrupt-free.

We also need a different term for "impacts existing deployments" than BREAKING CHANGE I feel.

@eladb
Copy link
Contributor

eladb commented Feb 4, 2019

We also need a different term for "impacts existing deployments" than BREAKING CHANGE I feel.

You are right. It's going to recreate a resource, but without data or availability loss, so I am okay with not indicating as a breaking change. Maybe we can devise some sort of a code in the commit title that we can later on expand in CHANGELOG?

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Feb 4, 2019

Maybe we can devise some sort of a code in the commit title that we can later on expand in CHANGELOG?

That's what I was thinking as well. What would be a good term though? DEPLOYMENT IMPACT?

@rix0rrr rix0rrr self-assigned this Feb 4, 2019
@rix0rrr rix0rrr requested a review from SoManyHs as a code owner February 6, 2019 10:36
@rix0rrr rix0rrr merged commit 0cc11ca into master Feb 6, 2019
@rix0rrr rix0rrr deleted the huijbers/fix-sns branch February 6, 2019 14:56
@NGL321 NGL321 added the contribution/core This is a PR that came from AWS. label Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
3 participants