sign-in redirect response from Next.js adapter is not returned immediately with Lambda Web Adapter + function URL + CloudFront

[tmokmss]

Before opening, please confirm:

• [x] I have searched for duplicate or closed issues and discussions.
• [x] I have read the guide for submitting bug reports.
• [x] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

Next.js

Amplify APIs

Authentication

Amplify Version

v6

Amplify Categories

auth

Backend

CDK

Environment information

  System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 123.75 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.19.0 - ~/.volta/tools/image/node/20.19.0/bin/node
    Yarn: 1.22.19 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
    npm: 11.2.0 - ~/.volta/tools/image/npm/11.2.0/bin/npm
    pnpm: 9.15.0 - ~/.volta/bin/pnpm
  Browsers:
    Chrome: 137.0.7151.68
    Edge: 136.0.3240.64
    Safari: 18.5
  npmPackages:
    @types/node: ^20 => 20.17.50 
  npmGlobalPackages:
    corepack: 0.31.0
    npm: 10.8.2

Describe the bug

When I deploy a Next.js app using a Lambda Web Adapter (LWA) function URL and CloudFront, the sign-in redirect response from the Amplify Next.js Adapter is returned to the client not immediately, but one minute after accessing the sign-in endpoint (which is CloudFront's default origin request timeout).

This seems to be an issue on the CloudFront side (internal ticket ID V1680564733), but resolving the root cause seems taking time. (I'll omit the details of this issue because the aforementioned ticket contains all of them.)

We have a workaround though: we can add a response body to the redirect response (e.g., "OK") to make CloudFront work properly. Currently, however, Amplify library users cannot modify the response directly because it is completely encapsulated. We can use libraries like patch-package, but it would be beneficial for the Amplify adapter itself to support this workaround in the meantime.

Expected behavior

The redirect response is returned immediately.

Reproduction steps

Configure next.js app to use LWA + fURL (response stream enabled) + CloudFront with Cognito and Amplify Next.js adapter. Then access the sign-in endpoint.

One example project using the configuration is here: https://github.com/aws-samples/remote-swe-agents

And an example implementation of the workaround is here: https://github.com/aws-samples/remote-swe-agents/pull/101/files. Basically you can just replace null to some string.

-    return new Response(null, {
+    return new Response("ok", {
         status: 302,
         headers,
     });

I wonder if this issue also occurs with Amplify hosting.

Code Snippet

// Put your code below this line.

Log output

// Put your logs below this line

aws-exports.js

No response

Manual configuration

No response

Additional configuration

No response

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

No response

[adrianjoshua-strutt]

Hello @tmokmss, thank you for creating this issue. We will look into the request and will get back to you with our findings.

[bestickley]

Hi, I'm the author of the internal ticket mentioned above. I've been experiencing this issue with Next.js/CloudFront/Lambda Function URLs for the past year and have used the above workaround. Just wanted to clarify, the current working theory is that the issue is with Lambda Function URL Streaming (not CloudFront) but that's not confirmed yet.

[nadetastic]

Hi @tmokmss / @bestickley thank you for the feedback and the information on the workaround patch. We are currently evaluating how this can be implemented within the NextJS adapter without cause any unintended side effects.

To further assist with this, can you provide a simple application that reproduces this issue? So far we haven't been able to successfully reproduce it. Thanks

[tmokmss]

Thanks @bestickley I updated the issue description as well :)

@nadetastic Thank you for the investigation. I made a smaller project for reproduction with only cloudfront, lambda, and cognito resources:

git clone https://github.com/aws-samples/serverless-full-stack-webapp-starter-kit.git -b repro
cd serverless-full-stack-webapp-starter-kit
cd cdk
npm ci
npx cdk bootstrap
npx cdk deploy --all

The cdk finally outputs a cloudfront URL. Then you can access the sign-in endpoint.

curl -vvv <cloudfront url>/api/auth/sign-in

What I found now is that the behavior might depend on AWS accounts. I tried it in two acccounts, and in one account the issue always reproduced (2/2), but in another it never did (0/4). I think you can try several accounts to reproduce it.

When it reproduces, the curl outputs the following error:

* HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
* Connection #0 to host redacted.cloudfront.net left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

[adrianjoshua-strutt]

Hi @tmokmss,

I investigated the issue and setup your example project. Unfortunately, however, I was not able to reproduce the error. I deployed the project to 5 accounts and none of them seemed to cause any issues.

To help identify the root cause: Are you able to investigate if there is a relevant difference between the AWS account that caused the error and the AWS account that worked fine?

Thank you!

[tmokmss]

Hi @adrianjoshua-strutt , Thank you very much for taking the time. I might be missing some conditions necessary to reproduce the issue, but I can't pinpoint exactly what they are. However, our support team has confirmed that the issue exists in the original ticket.

I'd like to share the domain in which the issue reproduces: https://d36ct1fy3cnuof.cloudfront.net. Press the sign-in button to see how broken the UX is (no login is required). You can also curl the problematic endpoint.

curl -v https://d36ct1fy3cnuof.cloudfront.net/api/auth/sign-in

Thanks again for taking the time. Hope this helps!