functions-action hangs when /api/deployments/latest returns stale incomplete deployment

[samkellerhals]

Description

We encountered a case where Azure/functions-action@v1 hung indefinitely during ZIP deploy, even though the Azure Function deployment had completed successfully.

After investigation, the root cause was a stale, incomplete deployment record in Kudu. The action appears to rely on /api/deployments/latest for polling deployment status. In our case, that endpoint returned an older, incomplete deployment (status = 1, complete = false) instead of the newly triggered deployment, causing the action to wait forever.

Environment

• Azure Functions (Linux Consumption plan)
• Deployment method: ZIP Deploy via Azure/functions-action@v1
• Remote build disabled:
  • scm-do-build-during-deployment: false
  • enable-oryx-build: false

Symptoms

GitHub Action output:

Package deployment using ZIP Deploy initiated.

However, the job never completed.

Meanwhile, Azure showed the deployment as successful:

{
  "status": 4,
  "complete": true,
  "end_time": "...",
  "last_success_end_time": "..."
}

The root cause was found by calling: GET https://<app>.scm.azurewebsites.net/api/deployments/latest , which returned an older deployment:

{
  "status": 1,
  "progress": "Running oryx build...",
  "complete": false,
  "end_time": null
}

This was a stale Oryx deployment that had never completed.

The new deployment (status = 4, complete = true) existed in /api/deployments, but /latest continued to return the incomplete record.

Because the action seems to poll /latest, it waited indefinitely for completion.

How we fixed it

Deleting the stale deployment record via:

DELETE /api/deployments/<stale-id>

immediately resolved the issue.

After deletion:

/api/deployments/latest returned the correct (successful) deployment, and then the GitHub Action completed normally.

Expected Behavior

The action should not hang indefinitely if /latest resolves to a stale, non-terminal deployment record unrelated to the currently triggered deploy.

Possible improvements:

Poll the specific deployment ID returned from the ZIP deploy call instead of relying on /latest

Or ignore unrelated stale incomplete deployments.

I am happy to provide any additional logs if helpful.