Next.js redirects in config broken in rc15

[cmanou]

In 3.0.0rc15 redirects in next config such as :

    redirects: () => [{ source: '/settings', destination: '/settings/general', permanent: false }],

No longer seem to work they are working in rc14, my open-next config:

default: {
    override: {
      wrapper: 'aws-lambda-streaming',
    },
  },

From the lambda logs it looks like its being invoked But the browser just hangs and says the connection is lost for safari and in chrome it takes 20s which is some timeout.

[conico974]

Could you create a minimum repro ? rc14 is the one with broken redirect for me, and rc15 does work for all the e2e tests with redirect https://github.com/sst/open-next/blob/v3-rc/examples/app-router/next.config.js

[cmanou]

Okay reproduction here https://github.com/cmanou/ion-open-next-reproduction.

Its currently deployed (I can send you the current url on discord if that helps)

• In safari it just does this

• in chrome it waits for the function timeout and then redirects after 20 seconds

[cmanou]

Additionally curl shows similar to chrome, where the timeout causes the headers to be returned

❯ curl https://#########.cloudfront.net/settings -vvvvv
*   Trying 108.158.29.17:443...
* Connected to #########.cloudfront.net (108.158.29.17) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.cloudfront.net
*  start date: Oct 10 00:00:00 2023 GMT
*  expire date: Sep 19 23:59:59 2024 GMT
*  subjectAltName: host "#########.cloudfront.net" matched cert's "*.cloudfront.net"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://#########.cloudfront.net/settings
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: #########.cloudfront.net]
* [HTTP/2] [1] [:path: /settings]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
> GET /settings HTTP/2
> Host: #########.cloudfront.net
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/2 307 
< content-type: application/json
< date: Thu, 18 Apr 2024 11:34:06 GMT
< x-amzn-requestid: bc0a302e-8eed-4c5b-9339-cf763002030f
< content-encoding: identity
< x-opennext: 1
< location: /settings/general
< x-cache: Miss from cloudfront
< via: 1.1 ############.cloudfront.net (CloudFront)
< x-amz-cf-pop: SYD3-P2
< x-amz-cf-id: V9X4FmYdtMeBdEKQeuAejDOp2NZffXc1gylZ_IK1jTiKh0lvJncUJg==
< 
* HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
* Connection #0 to host #########.cloudfront.net left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)

~ took 20s 

[conico974]

Link to the discord threads discussing this https://discord.com/channels/983865673656705025/1230482660913184800

TLDR; This is an issue with lambda itself and depending on the region and the account, you might not experience this issue at all. Lambda is also probably rolling out the fix

[conico974]

Fixed in 3.0.3 Be aware that there is another issue with streaming that cannot be fixed by us but only by aws. See https://discord.com/channels/983865673656705025/1249368592558985247