(integ-test): HttpApiCall seems to be broken

[kornicameister]

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

[ashishdhingra]

@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

[kornicameister]

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]

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;
}

[kornicameister]

@ashishdhingra any ideas?

[kornicameister]

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

[nmussy]

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]

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]

@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.