[Fleet Monitor] petry-projects/.github-private — .github/workflows/actions-fleet-monitor.yml #2362

Activity

1. don-petry

   added

   health-checkAutomated health check reportAutomated health check report

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   fleet-trackerTracked by the Actions Fleet MonitorTracked by the Actions Fleet Monitor

   on Oct 11, 2026
2. don-petry commented on Oct 11, 2026

   

   don-petry

   on Oct 11, 2026

   CollaboratorAuthor

   More actions

   Dev-Lead Implementation Plan

   Issue: #2362 — [Fleet Monitor] petry-projects/.github-private — .github/workflows/actions-fleet-monitor.yml

   Scope

   Investigation only. The root cause was already fixed on main, so no code change is planned.

   Findings

   • The one failure in the monitored window is run 38141887715. It was the 2026-10-11 13:06 UTC scheduled run at 3013fbd, and it aborted with scripts/fleet_monitor.sh: line 221: legacy_attr_file: unbound variable. The scheduled runs from 2026-10-04 to 2026-10-10 failed early in the same way.
   • This is the defect tracked in Fleet Monitor aborts every run: legacy_attr_file used before it is created (unbound variable at fleet_monitor.sh:221) #2277. feat: implement issue #2277 — Fleet Monitor aborts every run: legacy_attr_file used before it is created (unbound variable at fleet_monitor.sh:221) #2278 (9663114) fixed it by creating legacy_attr_file before the per-repo loop.
   • Both runs after the fix succeeded: 38150568552 at 9663114 and 38158033007 at 684e4b9. The second one is the run that filed this issue.
   • So the 50% (1/2) rate is one failure from before the fix plus one success from after it. The failure rate should fall back under the threshold once the pre-fix run leaves the 1-day lookback window.

   Implementation Checklist

   • None. The regression is already covered by tests/fleet_monitor_tempfile_order.bats (added in feat: implement issue #2277 — Fleet Monitor aborts every run: legacy_attr_file used before it is created (unbound variable at fleet_monitor.sh:221) #2278).

   Test Command

   bats tests/fleet_monitor_tempfile_order.bats tests/fleet_monitor_run.bats. All 17 pass locally on 85511b0. This result comes from a local workspace and is provisional.

   Follow-up

   Check that the next scheduled run (06:27 UTC) succeeds. If it does, close this as already resolved by #2278.
3. don-petry

   transferred this issue fromcombsmith/.github-privateon Oct 15, 2026
4. don-petry

   transferred this issue fromcombsmith/.github-privateon Oct 16, 2026
5. don-petry

   transferred this issue fromcombsmith/.github-privateon Oct 17, 2026
6. github-actions

   added

   bugBug reportsBug reports

   on Oct 17, 2026
7. github-actions commented on Oct 17, 2026

   

   github-actionsBot

   on Oct 17, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for flagging this, and for the detailed metrics from the Fleet Monitor. This looks like an automated degradation report: 1 of 3 runs of actions-fleet-monitor.yml failed, and the p50 and p95 durations (~1500s) are long. Could you share the failing run's error output or the step that failed, and say whether you expected a run to take that long? That would help us tell a transient failure from a regression.
8. don-petry

   transferred this issue fromcombsmith/.github-privateon Oct 18, 2026
9. don-petry

   closed this as completedon Oct 18, 2026
10. github-actions commented on Oct 18, 2026

    

    github-actionsBot

    on Oct 18, 2026 – with GitHub Actions

    Contributor

    More actions

    Thanks for flagging this, and for the detailed Fleet Monitor report! The monitor shows one failed run out of three for actions-fleet-monitor.yml in petry-projects/.github-private, with p50 and p95 durations of about 1500s. Could you link the specific failed run, or paste the failing step's error output, so we can tell whether this is a real workflow defect or a transient failure such as a timeout or rate limit?