Deployment Failure Reason: Web app warm up timed out

[dfahlander]

Describe the bug

I have a static nextjs app that used to work for 6-7 weeks ago but have stopped working even for the smallest change. I even reverted the branch to the exact commit that was successfully built last time and it still fails with "Deployment Failure Reason: Web app warm up timed out. Please try again later." after having being stuck in "Status: InProgress." for 10 minutes.

Last successful build: https://github.com/dexie/dexie-cloud/actions/runs/7733486859/job/21085673246 Last failing build (same git commit as the successful build after i reverted to that commit in trying to isolate the culprit): https://github.com/dexie/dexie-cloud/actions/runs/8377209871/job/22938762204

The github repo is private (https://github.com/dexie/dexie-cloud) but I can add access to anyone that can help me troubleshoot this.

To Reproduce Steps to reproduce the behavior:

1. Trigger build by restarting the following Github Actions job: https://github.com/dexie/dexie-cloud/actions/runs/8377209871/job/22938762204 (I can provide access to whom may look into this)
2. See error "Deployment Failure Reason: Web app warm up timed out. Please try again later." after having being stuck in "Status: InProgress." for 10 minutes.
3. Compare it with the last successful job https://github.com/dexie/dexie-cloud/actions/runs/7733486859/job/21085673246 that is based on the exact same commit.

Github workflow file (.github/workflows/azure-static-web-apps-proud-meadow-0514cdf10.yml):

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - dxcman
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - dxcman

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v3
        with:
          submodules: true
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0514CDF10 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/libs/dexie-cloud-manager/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "" # Built app content directory - optional
          app_build_command: "yarn build"
          api_build_command: "rm -rf ./node_modules/@next/swc-* && rm -rf ./.next/cache"
          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          app_location: "/libs/dexie-cloud-manager/" # App source code path
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_PROUD_MEADOW_0514CDF10 }}
          action: "close"

Expected behavior I expect the build to complete and publish the new version of the app.

Screenshots

Device info (if applicable):

N/A

Additional context

-

[znssss]

having the same issue :(

[dfahlander]

My solution was to publish my next project on an azure webapp instead. It was some cumbersome work now it's live in that way instead. This time without CI but I will add that later. At least there aren't a as much of magic going on so it feels safer also. I will go deleting the static web app and the workflow.

[pakeecbala]

Same issue here!

[znssss]

My solution was to publish my next project on an azure webapp instead. It was some cumbersome work now it's live in that way instead. This time without CI but I will add that later. At least there aren't a as much of magic going on so it feels safer also. I will go deleting the static web app and the workflow.

will try if needed. i just re-ran the job and it passed second time

[tylerlantern]

Same issue here

[liamgsmith]

Same issue here, however randomly it will work.

However even if the deployment completes successfully, the static parts of the app work, however the interactivity doesn't & I get a strange redirect to localhost:8080 occurring.

I've deployed successfully with two nextjs sites; both into US-West1, one v12 with pages/api functions, the other a v14 no API routes and both are unusable after the successful deployments.

At this point and seeing the posts above; I don't believe Microsoft can advertise full NextJS support; it is certainly not turn key, and the documentation is woeful.

[shreeyash]

facing same issue.

[julianurregoar]

Same here :(

[dfahlander]

I was actually happy that I went into this problem because it forced me out from publishing my nextjs app using static website. The results of migrating from static to web app:

• Costs decreased a lot
• Speed improved significantly
• Less dependant on the pipeline yml magic

So to anyone reading this, my advice is: give normal web apps a try, no matter if you have this issue or not.

[julianurregoar]

@dfahlander I will move in that direction. Thanks for the advice!

[liamgsmith]

I would absolutely love to but I can’t seem to find a good set of instructions to allow SSR nextjs sites to work properly. Did you use any particular resources?On 5 Jun 2024, at 23:45, David Fahlander @.***> wrote: I was actually happy that I went into this problem because it forced me out from publishing my nextjs app using static website. The results of migrating from static to web app:

Costs decreased a lot Speed improved significantly Less dependant on the pipeline yml magic

So to anyone reading this, my advice is: give normal web apps a try, no matter if you have this issue or not.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[dfahlander]

I would absolutely love to but I can’t seem to find a good set of instructions to allow SSR nextjs sites to work properly. Did you use any particular resources?On 5 Jun 2024, at 23:45, David Fahlander @.> wrote: I was actually happy that I went into this problem because it forced me out from publishing my nextjs app using static website. The results of migrating from static to web app: Costs decreased a lot Speed improved significantly Less dependant on the pipeline yml magic So to anyone reading this, my advice is: give normal web apps a try, no matter if you have this issue or not. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>

I don't recall all I had to do, but there was a couple of tricks nescessary to avoid the functions becoming too heavy - found some hacks somewhere to add to the github actions yml file. Until it stopped working... :)

The reason I went for static site in the first place was that whenever I Googled about how to publish Next.js app to Azure, I got into some docs pages or blog posts about doing it as a static web site. Then I got stuck in it. So glad I'm using a normal web app now instead.

[cj-clifton]

Same issue here - very sporadic, deployment via github actions sometimes works, sometimes doesn't

[dharmendrasha]

same issue here

[saendu]

For me the error came when introducing a middleware to secure my whole application. This middleware did not have an exception for the .swa/health probe that Girhub actions probabbly use to check the up and running app. This caused the timeout. Adding |\.swa/health| resolved the issue for me. Check this issue for more infos: https://github.com/Azure/static-web-apps/issues/1404

[rduque1]

Thanks Saendu, that worked