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

feat(apigateway): WebSocketIntegrationResponse implementation #29661

Closed

Conversation

nmussy
Copy link
Contributor

@nmussy nmussy commented Mar 31, 2024

Issue # (if applicable)

None as far as I could tell, related to #29562.

Reason for this change

While it is possible to use the L1 CfnIntegrationResponse construct, it's not trivial given the WebSocketRouteIntegration are currently bound to the WebSocketIntegration on the fly.

Description of changes

  • Added a basic L2 WebSocketIntegrationResponse construct
    • Gave two-way WebSocketIntegrations (capable of setting IntegrationResponse) a responses config prop, as well as a addResponse method. This allows me to check that there are no repeat responseKeys, and that returnResponse is active if there are responses set
    • An intermediate CustomResponseWebSocketRoute abstract class was created to isolate WebSocketLambdaIntegration, which does not support response customization
  • Added a WebSocketIntegrationResponseKey helper class to access common and to generate custom responseKeys

Description of how you validated changes

Unit tests were added/modified, and existing integration files were extended to include responses

Checklist


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

@github-actions github-actions bot added distinguished-contributor [Pilot] contributed 50+ PRs to the CDK p2 labels Mar 31, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team March 31, 2024 14:13
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

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

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

Comment on lines +294 to +295
// FIXME change to a warning?
throw new Error('Setting up integration responses without setting up returnResponse to true will have no effect, and is likely a mistake.');
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure which is best here, as far as I can tell the web console (and thus I assume Cfn) allows the user to create responses, with a simple notice:

image

It does feel like quite a big pitfall though, I don't think an exception is unwarranted

Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like a warning would be more suitable here if it's something that's possible to do from the web console, is there a very strong reason you think we should throw an exception instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can see a stronger reason to allow this in the web console, say if you want to add responses first, before enabling returnResponse. With IaC, you can just block comment both the integration responses and the property. I don't mind just showing a warning, an exception just seemed like it would save people time debugging something that could could be easily missed at deploy time

Copy link
Contributor

Choose a reason for hiding this comment

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

Rather than doing this validation after the fact, we should structure these inputs so that they are tightly coupled and so that users can't do this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ultimately, what I think should be done here is to deprecate the returnResponse field and update it to response that takes in a enum like class with two options: DEFAULT, which is what it's doing now, and customResponse() that is a function that creates all the stuff you're creating in this PR. What do you think?

Comment on lines 79 to 83
/**
* Integration response ID
*/
public readonly integrationResponseId?: string;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assume this was added in anticipation of an implementation of integration responses, but serves no purpose and cannot store multiple responses

Copy link
Contributor

Choose a reason for hiding this comment

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

Technically, we need to deprecate this, not delete it. While it doesn't actually do anything, the removal is a breaking change. This is a stable module so we can't allow it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, can we get access to this id in this scope? If so, why not just set it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My main issue is that there can be multiple integrationResponseId, it would need to be a string[] to be usable. I don't think setting it to the first value is worth the confusion. I can leave it up and just @deprecrate it, but again, I think it's needlessly confusing given it was never implemented

Comment on lines 311 to 314
// FIXME any better way to generate a unique id?
Names.nodeUniqueId(this.integration.node) + slugify(responseProps.responseKey.key) + 'IntegrationResponse',
{ ...responseProps, integration: this.integration },
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unsure this is the best way to generate this ID, feedback would be appreciated

@nmussy
Copy link
Contributor Author

nmussy commented Apr 1, 2024

AWS_PROXY, implemented as WebSocketLambdaIntegration, is the only currently available integration type that does not support IntegrationResponse:

image

@aws-cdk-automation aws-cdk-automation dismissed their stale review April 1, 2024 16:44

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

@aws-cdk-automation aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Jun 21, 2024
@TheRealAmazonKendra
Copy link
Contributor

I forgot to add, you added some changes that were actually unrelated to this implementation. Can you please separate those out into a separate PR?

Co-authored-by: Kendra Neil <[email protected]>
@mergify mergify bot dismissed TheRealAmazonKendra’s stale review June 21, 2024 21:08

Pull request has been modified.

@aws-cdk-automation aws-cdk-automation added the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Jun 21, 2024
@nmussy
Copy link
Contributor Author

nmussy commented Jun 22, 2024

I forgot to add, you added some changes that were actually unrelated to this implementation. Can you please separate those out into a separate PR?

WebSocketMockIntegrationProps.requestTemplates and .templateSelectionExpression were moved to #30622

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: ddbf57b
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@pahud
Copy link
Contributor

pahud commented Sep 25, 2024

This PR is pending for community review now.
Please check https://github.com/aws/aws-cdk/wiki/CDK-Community-PR-Reviews for more details.
We need at least one community approving review before it could bump to pending maintainer review.

mergify bot pushed a commit that referenced this pull request Jan 15, 2025
…0622)

### Issue # (if applicable)

None

### Reason for this change

Unlike the other integrations, `WebSocketMockIntegration` did not have a props interface, and was missing a few properties. This PR does not include integration responses, they are already being implemented in #29661 

### Description of changes

* Added `requestTemplates` and `templateSelectionExpression` to the newly created `WebSocketMockIntegrationProps`

### Description of how you validated changes

Unit and integration tests were updated

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@aws-cdk-automation
Copy link
Collaborator

This PR has been in the MERGE CONFLICTS state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

@aws-cdk-automation
Copy link
Collaborator

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

@aws-cdk-automation aws-cdk-automation added the closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. label Feb 2, 2025
Copy link

github-actions bot commented Feb 2, 2025

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 2, 2025
@aws-cdk-automation aws-cdk-automation removed the pr/needs-community-review This PR needs a review from a Trusted Community Member or Core Team Member. label Feb 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
closed-for-staleness This issue was automatically closed because it hadn't received any attention in a while. distinguished-contributor [Pilot] contributed 50+ PRs to the CDK p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants