Serverless-next.js: "InvalidArgument: The parameter MinTTL is required" for older serverless-nextjs versions (1.16 and below)

[SarKurd]

Describe the bug
Deployments suddenly broke for older version 1.16 and below and throws InvalidArgument: The parameter MinTTL is required.

Recent changes to TTL may caused that as serverless-nextjs might pick latest aws-cloudfront version

To Reproduce
deploy any simple website with almost zero config with @sls-next/[email protected]

Expected behavior

Expect to not throw

Desktop (please complete the following information):

• OS: MacOS and Linux tested
• Serverless-nextjs version: @sls-next/[email protected]

[dphang]

It should be because the publish step was publishing non-exact versions of the dependencies, so it may pick later versions of the dependencies. I fixed it here: https://github.com/serverless-nextjs/serverless-next.js/commit/ecce5e90b61f4eb763eb8a393de90001e1da88f7, but it would only apply for the recent releases and future release.

Not sure how we can fix this for previous versions, as I don't think NPM allows republishing an older version anymore. Any thoughts @danielcondemarin?

I would recommend to upgrade to 1.17. If you are using custom cache behavior, note that you now should specify all TTLs (minTTL, maxTTL, defaultTTL): https://github.com/serverless-nextjs/serverless-next.js#custom-cloudfront-configuration.

[SarKurd]

I was worried that it may come up again in the future but glad you have fixed that, will upgrade mine on Monday

[browniefed]

Upgraded to 1.17 and running into this.

[dphang]

Can you please post your serverless.yml configuration. If you are using custom cache behavior, note that you now should specify all TTLs (minTTL, maxTTL, defaultTTL): https://github.com/serverless-nextjs/serverless-next.js#custom-cloudfront-configuration.

Previously the CloudFront library was only accepting one parameter ttl which sets the same for min, max, default TTL, which was not as good since you should be able to set individual TTLs. I made a change which may be breaking in 1.17.

Unfortunately it may affect older versions as well because of the versioning issue mentioned here: https://github.com/serverless-nextjs/serverless-next.js/issues/626#issuecomment-699553602. If you are having issues for these versions, please try setting minTTL, maxTTL, defaultTTL inputs instead.

I have already fixed the versioning issue and also changelogs/releases should be now published correctly on GitHub Releases page so it would be clearer in the future. Sorry for the inconvenience and thank you for your patience!

[browniefed]

Ah this was my bad.
I installed a new version but forgot to update the serverless.yml file so serverless file had 1.17.0-alpha.9 but I had 1.17.0-alpha13 and also tested out 1.17.0 without editing serverless file.

I updated the serverless.yml and re-deployed and all is good. The default TTLs were fine so I don't have any config besides

```
name: actions

actionsNextApp:
component: "@sls-next/[email protected]"
inputs:
useServerlessTraceTarget: true
domain:
- ${env.SUB_DOMAIN}
- ${env.DOMAIN}
memory: 2048
````

[dphang]

Cool, thanks for that! Will close it then.

[Bryceacampbell]

I am getting this issue on @sls-next/[email protected]. Here is my serverless.yml file

myNextApplication:
    component: "@sls-next/[email protected]" # it is recommended you pin the latest stable version of serverless-next.js
    inputs:
        domain: ["${env.PASSING_URL}", "tesla.com"]
    build:
        env:
            stage: ${env.PASSING_STAGE}

Here is the error I am getting

966 | { InvalidArgument: The parameter MinTTL is required.
967 | at Request.extractError (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/protocol/rest_xml.js:53:29)
968 | at Request.callListeners (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
969 | at Request.emit (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
970 | at Request.emit (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/request.js:688:14)
971 | at Request.transition (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/request.js:22:10)
972 | at AcceptorStateMachine.runTo (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/state_machine.js:14:12)
973 | at /root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/state_machine.js:26:10
974 | at Request.<anonymous> (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/request.js:38:9)
975 | at Request.<anonymous> (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/request.js:690:12)
976 | at Request.callListeners (/root/.serverless/components/registry/npm/@sls-next/[email protected]/node_modules/aws-sdk/lib/sequential_executor.js:116:18)
977 | message: 'The parameter MinTTL is required.',
978 | code: 'InvalidArgument',
979 | time: 2020-09-28T17:40:47.116Z,
980 | requestId: '421d3a9a-6c0f-460c-bc6d-5628a5cd9136',
981 | statusCode: 400,
982 | retryable: false,
983 | retryDelay: 41.92838017369829 }

Any ideas what this could be?

[dphang]

@Bryceacampbell Please try latest 1.17.0 version (not alpha), as mentioned above there was a dependency versioning issue that caused old component versions to pull newer dependency versions. Unfortunately we can't republish older versions to npm :(

[Bryceacampbell]

@Bryceacampbell Please try latest 1.17.0 version (not alpha), as mentioned above there was a dependency versioning issue that caused old component versions to pull newer dependency versions. Unfortunately we can't republish older versions to npm :(

Thank you, this solved my issue and everything works fine.

[joebanks10]

Where can I find the default TTLs?

[dphang]

@joebanks10 it's buried in the code here: https://github.com/serverless-nextjs/serverless-next.js/blob/ca8094b4d9b9541493410dd830a3c85f54250448/packages/serverless-components/nextjs-component/src/component.ts#L281-L314.

All cache behaviors are now minTTL = 0 and maxTTL = 1 year and default TTLs is either 86400 seconds (1 day) for static asset cache behaviors or 0 (for API and default cache behavior). Individual paths may override this using Cache-Control header. For example, static S3 files override this when uploaded to S3.

[himynameistimli]

Is there a solution for folks that can't upgrade their serverless-component? We're stuck on 1.15.0 because upgrading causes some pages to show cloudfront 503 errors, but have been unable to diagnose the root cause from the cloudwatch logs.

[danielcondemarin]

Is there a solution for folks that can't upgrade their serverless-component? We're stuck on 1.15.0 because upgrading causes some pages to show cloudfront 503 errors, but have been unable to diagnose the root cause from the cloudwatch logs.

Have you tried using the latest stable ?

[paleite]

Version 1.17.1-alpha.3 is considered the latest version on npm, so it's likely that's the version your users will get when they install @sls-next/serverless-component, hence why people don't use the latest stable.

What you can do is to split your releases into different tags, so you have one tag that's "alpha/canary" and another tag that's "stable/latest".

Before upgrading a release to the "latest"-tag, you can use the "canary"-tag, so no users except for early adopters would be affected by it. Once the canary-version works well, you can release it as stable.

As an example, compare the "Current tags"-section from Next.js:

https://www.npmjs.com/package/next?activeTab=versions

compared to

https://www.npmjs.com/package/@sls-next/serverless-component?activeTab=versions

[himynameistimli]

@danielcondemarin yeah I've tried a few different versions, including 1.17.0.

When I update the component, my static pages that have SSG (funny that dynamic pages, and static pages with static props are fine) and some of my public files return Cloudfront 503's (NoSuchKey on CloudWatch)

[dphang]

@paleite thanks! We will look into tagging the versions differently so we can have a separate stable/alpha release

@himynameistimli if you are able to repro your issue and share it, I can take a better look at what's happening.

In meanwhile perhaps we could republish a 1.15 & 1.16 under a new version e.g 1.15-patch and 1.16-patch as a one time thing (with pinned dependencies) as a temp workaround? @danielcondemarin any thoughts how to do it? We just need to checkout the 1.15 and 1.16 tags and add --exact to the publish commands and I guess manually re-version them, though I'm not as familiar with Lerna so maybe you have a better idea.

[dphang]

@himynameistimli for now I published @sls-next/[email protected] (which is 1.15.0) with exact dependencies (https://www.npmjs.com/package/@sls-next/serverless-component/v/1.15.0-patch.0) so it should resolve this issue. Let me know if this works.

[paleite]

@paleite thanks! We will look into tagging the versions differently so we can have a separate stable/alpha release

@himynameistimli if you are able to repro your issue and share it, I can take a better look at what's happening.

In meanwhile perhaps we could republish a 1.15 & 1.16 under a new version e.g 1.15-patch and 1.16-patch as a one time thing (with pinned dependencies) as a temp workaround? @danielcondemarin any thoughts how to do it? We just need to checkout the 1.15 and 1.16 tags and add --exact to the publish commands and I guess manually re-version them, though I'm not as familiar with Lerna so maybe you have a better idea.

Thanks, @dphang , I just saw that you've started releasing the alpha versions in their own tag. Works great! 🙂

[dphang]

@paleite Thanks. Hopefully this will make for a clearer separation. Next we could probably change to lerna fixed mode so that changelogs are merged together and less confusing to read...

[paleite]

@dphang that sounds like a great idea! I gotta admit I've been a bit confused when trying to understand which versions belong together 🙂

[dabit3]

Hey, I wanted to follow up here for some clarity.

I just created a new deployment tagged at "@sls-next/[email protected]" and it worked fine and as expected, does this mean the issue is now resolved for __1.16.0__?

[dphang]

@dabit3 Npm doesn't allow republishing the same package version (due to some past incidents where a package was unpublished and broke a lot of other packages) so nothing changed for 1.16, which doesn't use pinned dependencies.

If it started working I'm not sure why, perhaps it's picking up some different dependency version that is somehow compatible with your configuration.

It's recommended to go to 1.17 or later where internal dependencies are pinned.

If there's still any issue upgrading, please let me know and I can publish a patch for 1.16 if needed (I did for 1.15 as requested).