Next.js Incremental Site Regeneration not working

[marco910]

Please describe which feature you have a question about?
I'm trying to use Incremental Site Regeneration (ISR) with my Next.js site on AWS. I added the revalidate value to the returned props by getStaticProps but the pages are not being regenerated.

Provide additional details
I added the revalidate value to the returned props by getStaticProps and in package.json I set the build script to npm run build. Amplify also detects the Next.js project as SSR site.
I don't have amplify-js installed from NPM. Is the necessary?
When I try to access a new page like "/report/test" this is also not working and the page is not being generated.

Provide additional details e.g. code snippets
That's how my getStaticProps looks like:

export async function getStaticProps(context) {
  const client = Client();

  const report = await client.getByUID("report", context.params.slug, {
    lang: "de-de",
    fetchLinks: "service.title",
  });

  if (report === undefined || report.data.announcement.length === 0) {
    return {
      notFound: true,
    };
  }

  return {
    props: {
      report: report || null, 
    },
    revalidate: 300, 
  };
}

[ferdingler]

Hi @marco910, the ISR feature uses an SQS that gets created in your account and it is used to trigger the regeneration of pages. Could it be that your Lambda@Edge functions don't have the proper permissions to read/write to the queue? You'll need to check the logs of your L@E functions to determine this.

[marco910]

@ferdingler That can be possible. I'm having the issue on two sites at moment (both on Next.js) and on one of these I'm getting this error in CloudWatch:

ERROR	Invoke Error 	
{
    "errorType": "AccessDenied",
    "errorMessage": "Access to the resource https://sqs.us-east-1.amazonaws.com/ is denied.",
    "Type": "Sender",
    "Code": "AccessDenied",
    "Detail": "",
    "name": "AccessDenied",
    "$fault": "client",
    "$metadata": {
        "httpStatusCode": 403,
        "requestId": "f730964e-e3e8-5cbb-8c72-cfba7f7750f4",
        "attempts": 1,
        "totalRetryDelay": 0
    },
    "stack": [
        "AccessDenied: Access to the resource https://sqs.us-east-1.amazonaws.com/ is denied.",
        "    at /var/task/index-244fdbd1.js:2070:68",
        "    at step (/var/task/httpRequest-eeeab15a.js:89:23)",
        "    at Object.next (/var/task/httpRequest-eeeab15a.js:70:53)",
        "    at fulfilled (/var/task/httpRequest-eeeab15a.js:60:58)",
        "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"
    ]
}

I'm using the default role that is being created be Amplify. How should the role look like?

[EringiV3]

Hi @marco910, the ISR feature uses an SQS that gets created in your account and it is used to trigger the regeneration of pages. Could it be that your Lambda@Edge functions don't have the proper permissions to read/write to the queue? You'll need to check the logs of your L@E functions to determine this.

I ran into the same issue.
It seems that if I deploy to Amplify Console for the first time without ISR, then change the code to use ISR and deploy a second time, it fails to regenerate because it doesn't have sqs:SendMessage permission.
I would like the Amplify Console side to automatically assign sqs::SendMessage permissions when code that does ISR is detected.

[marco910]

@EringiV3 Thank you! The problem was that I used the app before the ISR implementation as a full static app. Now I created a whole new app in the Amplify Console and it's working!

For the future, it would be great if Amplify Console can assign the permissions afterwards, as you mentioned.

[incraigulous]

@ferdingler, which role do I assign the SQS permission to? The Lambda execution role?

[marco910]

@ferdingler, which role do I assign the SQS permission to? The Lambda execution role?

@incraigulous

I think you have to assign it to the role that you created and assigned in the Amplify Console.

[incraigulous]

I tried that and it didn't work. Following the Amplify documentation to switch from SSG to ISG does not work. It does not create the SQS resource, or set permission for it. I ended up recreating the project from scratch with ISG setup at project creation.

…

On Sun, Dec 19, 2021, 3:18 AM Marco Feicht ***@***.***> wrote: @ferdingler <https://github.com/ferdingler>, which role do I assign the SQS permission to? The Lambda execution role? @incraigulous <https://github.com/incraigulous> I think you have to assign it to the role that you created and assigned in the Amplify Console. — Reply to this email directly, view it on GitHub <#2347 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNC6GNY45CQMKDF3VCLK33URWPNRANCNFSM5G4QUJKA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[marco910]

@incraigulous You have to recreate the whole app in the Amplify Console (not only redeploying). Otherwise it won't work.

[incraigulous]

Thanks, Marcos. Recreating the app is what ended up working for me.

[arman-ab]

I fixed this without recreating app, find the role for the Lambd@edge function starting with “Default” and then update the roles permissions to allow the SQS:sendMessage action on the queue that was created for the ISR functionality. The queue’s name would be similar to the function names and the bucket that was created to hold the NextJS files. An example IAM policy would look as follow:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": "arn:aws:sqs:<region>:<accountId>:<queueName>.fifo",
            "Action": [
                "sqs:SendMessage"
            ]
        }
    ]
} 

[mingyeungs]

Came across the same issue today while adding ISR to a previously static next.js site.

For me, the IAM associated with Lambda already allows sqs:SendMessage (though I am not sure whether the "Resource" defined in the IAM is correct...), and redeploying doesn't make any difference.

The issue seems to be tied to the 'branch' instead of the app. So other than creating a new app, disconnecting the branch and reconnecting again also fix the problem. (need to wait > 20mins for Amplify to clear old resources before it allows me to reconnect though...)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.