Hi @Alvin Jhao I’ve implemented the monitor pipeline as advised using a Bash-based approach instead of PowerShell. The pipeline does the following:

✅ Fetches the build timeline using the Azure DevOps REST API
✅ Identifies stages that are failed, partiallySucceeded, or succeededWithIssues
✅ Constructs a retry payload for each stage and sends a PATCH request to retry it
✅ Verifies correct stage-to-job relationships via timeline structure

Here’s where I’m stuck now:

❌ Retry Requests Return HTTP 204

Although my pipeline correctly:

• Authenticates with $(System.AccessToken)

• Targets the correct stageId and buildId

• Sends the payload:

  `

  {
    "state": "retry",
    "forceRetryAllJobs": true,
    "retryDependencies": true
  }
  `
  

  I consistently receive: ` Retry failed for: <StageName> (HTTP 204) `

  Oddly, this used to work for stages like PublishArtifact in earlier runs, but no longer does — even with identical logic.

  ✅ What I’ve Already Verified

  • Service connection has Queue builds permission (confirmed in Project Settings)

  • Target builds are fully completed

  • Timeline output shows the stage identifier is present and correct

  • The payload matches Microsoft’s REST API spec

  • Even test pipelines with result: failed stages return 204

❓Questions

1. Are there specific reasons a stage becomes non-retryable (beyond completion)?

2. Could stage identifier fields being null (sometimes seen) block the retry?

3. Is there a way to programmatically verify retry eligibility before sending the PATCH?

Any help or insights would be appreciated!