What's wrong
MapWorkflowRunStatus (BuildMonitor/Providers/GitHub.cs:470-497) maps only Requested, Queued and InProgress explicitly. Octokit's WorkflowRunStatus also has Waiting and Pending. Waiting means a job targets a deployment environment with required reviewers and is waiting for approval. Both fall through to _ => RunStatus.Pending, which is the correct result. But the guard right after the switch then logs a Warning for any Pending result whose status isn't Requested or Queued:
Warning: GitHub: Unhandled workflow status: waiting, conclusion: - treating as Pending
Why it matters
A waiting run counts as ongoing, so RunSync polls it every 10-60 s, and a deployment can wait for approval for hours. Each poll adds another identical warning. Log keeps only MaxEntries = 1000 (Log.cs:33), so after roughly a few hours of one pending approval, the genuine warnings and errors (auth failures, rate limits) have been pushed out. They are gone by the time someone opens the log to see what went wrong.
Repro
Build an uninitialized WorkflowRun with Status = new StringEnum<WorkflowRunStatus>(WorkflowRunStatus.Waiting), call MapWorkflowRunStatus (via reflection), and inspect Log.GetEntries().
- Observed: returns
Pending, and one Warning entry is added per call.
- Expected: returns
Pending with no warning, since this is a known, normal state.
Suggested fix
- Add explicit arms
WorkflowRunStatus.Waiting => RunStatus.Pending and WorkflowRunStatus.Pending => RunStatus.Pending, and exclude both from the warning guard. The cleanest way is to make the guard fire only when the default arm was actually taken.
- If a warning is still wanted for a truly unknown status, log it once per distinct status value rather than once per poll.
- Add a test that
Waiting and Pending map to Pending without adding a log entry.
What's wrong
MapWorkflowRunStatus(BuildMonitor/Providers/GitHub.cs:470-497) maps onlyRequested,QueuedandInProgressexplicitly. Octokit'sWorkflowRunStatusalso hasWaitingandPending.Waitingmeans a job targets a deployment environment with required reviewers and is waiting for approval. Both fall through to_ => RunStatus.Pending, which is the correct result. But the guard right after the switch then logs a Warning for anyPendingresult whose status isn'tRequestedorQueued:Why it matters
A waiting run counts as ongoing, so
RunSyncpolls it every 10-60 s, and a deployment can wait for approval for hours. Each poll adds another identical warning.Logkeeps onlyMaxEntries = 1000(Log.cs:33), so after roughly a few hours of one pending approval, the genuine warnings and errors (auth failures, rate limits) have been pushed out. They are gone by the time someone opens the log to see what went wrong.Repro
Build an uninitialized
WorkflowRunwithStatus = new StringEnum<WorkflowRunStatus>(WorkflowRunStatus.Waiting), callMapWorkflowRunStatus(via reflection), and inspectLog.GetEntries().Pending, and one Warning entry is added per call.Pendingwith no warning, since this is a known, normal state.Suggested fix
WorkflowRunStatus.Waiting => RunStatus.PendingandWorkflowRunStatus.Pending => RunStatus.Pending, and exclude both from the warning guard. The cleanest way is to make the guard fire only when the default arm was actually taken.WaitingandPendingmap toPendingwithout adding a log entry.