Action fails after 1h+ despite successful deployment

[JacopoMadaluni]

Hello,
since a few months ago or so, the azure/webapps-deploy@v3 fails after 1h+ despite a successful deployment.
After this failure, I usually need to restart the app service in order for the changes to go through which isn't ideal.
Whilst this feels like a broader app service issue, I am not sure where to report it as it only happens when I use this action.

My usage in CI is as follows:

            - name: "Deploy to Azure Web App"
              id: deploy-to-webapp
              uses: azure/webapps-deploy@v3
              with:
                  app-name: "${{ env.APP_NAME }}"
                  slot-name: "production"
                  publish-profile: "${{ env.PUBLISH_PROFILE }}"
                  package: .

This is the error log from the action

Package deployment using OneDeploy initiated.
{
  id: '2b592529-1c8f-47da-8110-e9274d94f874',
  status: 3,
  status_text: 'Deployment has been stopped due to SCM container restart. The restart can happen due to a management operation on site. Do not perform a management operation and a deployment operation in quick succession. Adding a small delay can help avoid any conflicts.',
  author_email: 'N/A',
  author: 'N/A',
  deployer: 'OneDeploy',
  message: 'OneDeploy',
  progress: '',
  received_time: '2024-10-02T11:43:17.2412909Z',
  start_time: '2024-10-02T11:43:21.0833868Z',
  end_time: '2024-10-09T18:31:10.8607467Z',
  last_success_end_time: null,
  complete: true,
  active: false,
  is_temp: false,
  is_readonly: true,
  url: '***',
  log_url: '***,
  site_name: ***',
  build_summary: { errors: [], warnings: [] }
}
Updating submodules.
Preparing deployment for commit id '2b592529-1'.
PreDeployment: context.CleanOutputPath False
PreDeployment: context.OutputPath /home/site/wwwroot
Repository path is /tmp/zipdeploy/extracted
Running oryx build...
Command: oryx build /tmp/zipdeploy/extracted -o /home/site/wwwroot --platform nodejs --platform-version 18 -p virtualenv_name= --log-file /tmp/build-debug.log  -i /tmp/8dce2d76aa4ba8f -p compress_node_modules=tar-gz | tee /tmp/oryx-build.log
Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.20240424.1, Commit: d37b2225a252ab2c04b4726024d047cf01ea[13](https://github.com/***/actions/runs/11259972295/job/31310153804#step:12:14)18, ReleaseTagName: 20240424.1

Build Operation ID: ce22f881a5c78847
Repository Commit : 2b592529-1c8f-47da-8110-e9274d94f874
OS Type           : bullseye
Image Type        : githubactions

Detecting platforms...
Error: Failed to deploy web package to App Service.
Error: Deployment Failed, Package deployment using ZIP Deploy failed. Refer logs for more details.
App Service Application URL: http://***.azurewebsites.netPackage deployment using OneDeploy initiated.
{
  id: '2b592529-1c8f-47da-8110-e9274d94f874',
  status: 3,
  status_text: 'Deployment has been stopped due to SCM container restart. The restart can happen due to a management operation on site. Do not perform a management operation and a deployment operation in quick succession. Adding a small delay can help avoid any conflicts.',
  author_email: 'N/A',
  author: 'N/A',
  deployer: 'OneDeploy',
  message: 'OneDeploy',
  progress: '',
  received_time: '2024-10-02T11:43:17.2412909Z',
  start_time: '2024-10-02T11:43:21.0833868Z',
  end_time: '2024-10-09T18:31:10.8607467Z',
  last_success_end_time: null,
  complete: true,
  active: false,
  is_temp: false,
  is_readonly: true,
  url: '***',
  log_url: '***',
  site_name: '***',
  build_summary: { errors: [], warnings: [] }
}
Updating submodules.
Preparing deployment for commit id '2b592529-1'.
PreDeployment: context.CleanOutputPath False
PreDeployment: context.OutputPath /home/site/wwwroot
Repository path is /tmp/zipdeploy/extracted
Running oryx build...
Command: oryx build /tmp/zipdeploy/extracted -o /home/site/wwwroot --platform nodejs --platform-version 18 -p virtualenv_name= --log-file /tmp/build-debug.log  -i /tmp/8dce2d76aa4ba8f -p compress_node_modules=tar-gz | tee /tmp/oryx-build.log
Operation performed by Microsoft Oryx, https://github.com/Microsoft/Oryx
You can report issues at https://github.com/Microsoft/Oryx/issues

Oryx Version: 0.2.20240424.1, Commit: d37b2225a252ab2c04b4726024d047cf01ea[13](***/actions/runs/11259972295/job/31310153804#step:12:14)18, ReleaseTagName: 20240424.1

Build Operation ID: ce22f881a5c78847
Repository Commit : 2b592529-1c8f-47da-8110-e9274d94f874
OS Type           : bullseye
Image Type        : githubactions

Detecting platforms...
Error: Failed to deploy web package to App Service.
Error: Deployment Failed, Package deployment using ZIP Deploy failed. Refer logs for more details.
App Service Application URL: ***

[copdips]

I have similar issue, the app is deployed and restarted successfully, but from action side, it says 403 Forbidden.
I'm using azure/login@v2 with client id and client secret to authenticate.
last working date was on (same code): 2024.09.10

logs from Azure APP:

logs from Github Actions:

retried in debug mode, it seems that github action could not get the correct deploy status, so it keeps retrying during one hour.
The status shown in Azure WebApp is Success (Actif) OneDeploy, and the whole deployment took just several seconds.

[copdips]

When reviewing the debug logs, it appears that the system is checking the wrong deployment ID, rather than the one just deployed.

According to the action logs, the deployment ID is 4ec00f60-6727-4255-a7ed-ceee3c24294b, which corresponds to a failed deployment from five hours ago. Since this incorrect deployment failed, its status remains stuck at Building and Deploying.

I suspect there may be an issue at the Azure WebApp API level.
Tested locally with az webapp deploy, same issue.

For another web app, the same code works well, so it seems that as long as a web app has no failed deployments, everything functions correctly, and the API returns the correct deployment ID. However, for a web app with a failed deployment, the API consistently returns the failed deployment ID instead.

@JacopoMadaluni @ShilpiRachna1
Could you please have a look ?

[ShilpiRachna1]

@JacopoMadaluni , @copdips - We are working on fixing this. Will share an update on ETA soon