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.

Sign up for GitHub

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

Jump to bottom

(integ-test): HttpApiCall seems to be broken #30327

Open
kornicameister opened this issue May 24, 2024 · 8 comments · May be fixed by #30361
Open

(integ-test): HttpApiCall seems to be broken #30327

kornicameister opened this issue May 24, 2024 · 8 comments · May be fixed by #30361
Labels
@aws-cdk/integ-tests bug This issue is a bug. effort/medium Medium work item – several days of effort p2

Comments

@kornicameister
Copy link
Contributor

kornicameister commented May 24, 2024 •
edited
Loading

Describe the bug

I am trying to build a test that codes roughly does:

const getUploadUrl = integ.assertions
  .httpApiCall(`${testStack.apiUrl}outbox/${id}`, {
    method: 'PUT',
  })
  .expect(
    test.ExpectedResult.objectLike({
      status: 201,
      headers: {
        'content-type': ['application/json'],
      },
      body: {
        id: emailId,
      },
    }),
  )
  .waitForAssertions();
const uploadUrl = getUploadUrl.getAttString('body.uploadUrl');

as you can see I am trying to get my hands on uploadUrl from response body.
the assertion expressed in expect works fine (although there's no checkup for uploadUrl but just because I am not sure if I can nest expectation). Still, I am confident that uploadUrl is present in response body based on logs.

Is httpApiCall broken? I have located a lot of examples where getAtString is used in cdk own test suites. Difference is that it is rather used with awsSdkCall or lambdaInvokeFunction rather then httpApiCall.

Use case

Use case is to be able to integ test parts of bigger component.
Without a need to deploy the whole component.

Expected Behavior

I can obtain part of response via HttApiCall

Current Behavior

Test fails with Vendor response doesn't contain apiCallResponse.body.uploadUrl

Reproduction Steps

import 'source-map-support/register';

import * as test from '@aws-cdk/integ-tests-alpha';
import * as cdk from 'aws-cdk-lib';

const app = new cdk.App({
  analyticsReporting: false,
  stackTraces: true, 
});

const testStack = new cdk.Stack(app, 'repro-api-stack');
const integ = new test.IntegTest(app, 'repro-api-test', {
  testCases: [testStack],
});
const apiCall = integ.assertions.httpApiCall(
  'https://cat-fact.herokuapp.com/facts',
);
const value = apiCall.getAttString('body.0.user');

integ.assertions
  .httpApiCall(`https://cat-fact.herokuapp.com/users/${value}`)
  .expect(
    test.ExpectedResult.objectLike({
      status: 404,
    }),
  );

Possible Solution

N/A

Additional Information/Context

N/A

CDK CLI Version

2.142.1

Framework Version

No response

Node.js Version

20.8

OS

MacOS sierra

Language

TypeScript

Language Version

5.4

Other information

No response
@kornicameister kornicameister added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels May 24, 2024
@ashishdhingra
Copy link
Contributor

@kornicameister Good morning. Somehow, the below code works with CDK version 2.143.0:

import 'source-map-support/register';

import * as test from '@aws-cdk/integ-tests-alpha';
import * as cdk from 'aws-cdk-lib';

const app = new cdk.App({
  analyticsReporting: false,
  stackTraces: true, 
});

const testStack = new cdk.Stack(app, 'repro-api-stack');
const integ = new test.IntegTest(app, 'repro-api-test', {
  testCases: [testStack],
});
const apiCall = integ.assertions.httpApiCall(
  'https://cat-fact.herokuapp.com/facts',
);
const value = apiCall.getAttString('body.0.user');

integ.assertions
  .httpApiCall(`https://cat-fact.herokuapp.com/users/${value}`)
  .expect(
    test.ExpectedResult.objectLike({
      status: 404,
    }),
  );

Is this failing at your end? Please confirm along with the error.

In your previous code snippet, did you intend to use body.0.uploadUrl?

Thanks,
Ashish

@ashishdhingra ashishdhingra added response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. and removed needs-triage This issue or PR still needs to be triaged. labels May 24, 2024
@kornicameister
Copy link
Contributor Author

I bumped the version, took code from your snippet above and it failed:

Failed resources:
reproapitestDefaultTestDeployAssertA03A3219 | 9:46:24 PM | CREATE_FAILED        | Custom::DeployAssert@HttpCall                          | repro-api-test/DefaultTest/DeployAssert/HttpApiCall420eb7584d44d218b546a254d24187f3/Default/Default (HttpApiCall420eb7584d44d218b546a254d24187f3) CustomResource attribute error: Vendor response doesn't contain apiCallResponse.body.0.user attribute in object arn:aws:cloudformation:eu-central-1:00000000000:stack/reproapitestDefaultTestDeployAssertA03A3219/610896c0-1acf-11ef-bba5-06dfe13ba9f1|HttpApiCallcatfactherokuappcomfacts77c13b1c90b3620a2c6e32ccb72dd4b9|98bf9533-07c3-4b8e-b76d-2825b0abf30c

So.. it is a puzzle.

I don't know if that's relevant but to further describe my environment;

  • I am using non default defaultStackSynthesizer because of using non default toolkit name
  • I have esbuild that is installed locally

@kornicameister
Copy link
Contributor Author

In your previous code snippet, did you intend to use body.0.uploadUrl?

No, in the very first snippet (from opening comment in issue) I am in fact expecting uploadUrl to be returned in top root object.
Response's schema is loosely:

{
   id: string;
   uploadUrl: string;
}

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label May 25, 2024
@kornicameister
Copy link
Contributor Author

@ashishdhingra any ideas?

kornicameister added a commit to kornicameister/repro-aws-cdk-30327 that referenced this issue May 27, 2024
@kornicameister
chore: reproduction for aws/aws-cdk#30327
5e4010d
@kornicameister
Copy link
Contributor Author

I had created https://github.com/kornicameister/repro-aws-cdk-30327 that reproduces bug for me.
Created today via cdk init

@github-actions github-actions bot mentioned this issue May 27, 2024
Closed
@nmussy
Copy link
Contributor

nmussy commented May 27, 2024

This might be related to my PR #29705, since it was the last change made to http-call.ts. I'll have a look later today 👍

@nmussy
Copy link
Contributor

nmussy commented May 28, 2024 •
edited
Loading

This ended up being unrelated to my change, the HTTP handler just did not implement the flattenResponse feature that the SDK handler did:

aws-cdk/packages/@aws-cdk/integ-tests-alpha/lib/assertions/providers/lambda-handler/http.ts

Lines 25 to 27 in a2e8dc5

return {
apiCallResponse: result,
};

aws-cdk/packages/@aws-cdk/integ-tests-alpha/lib/assertions/providers/lambda-handler/sdk.ts

Lines 18 to 22 in a2e8dc5

let resp: AwsApiCallResult | { [key: string]: unknown };
if (request.outputPaths || request.flattenResponse === 'true') {
// Flatten and explode JSON fields
const flattened = flatten(deepParseJson({ apiCallResponse: response }));
resp = request.outputPaths ? filterKeys(flattened, request.outputPaths) : flattened;

I'm going to open a PR to solve this issue

@kornicameister
Copy link
Contributor Author

@nmussy appreciate it.

I was blocked by the lack of it and had to skip an important part of the integration tests because of it. Having it is something I look forward to.

@nmussy nmussy linked a pull request May 28, 2024 that will close this issue
Open
1 task
@github-actions github-actions bot mentioned this issue Jun 1, 2024
Closed
@ashishdhingra ashishdhingra added p2 effort/medium Medium work item – several days of effort labels Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
@aws-cdk/integ-tests bug This issue is a bug. effort/medium Medium work item – several days of effort p2
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(integ-tests): http flattenResponse nmussy/aws-cdk
3 participants
@kornicameister @nmussy @ashishdhingra