Dependabot PRs stuck BLOCKED despite auto-merge enabled and all checks green (PhotoCleaner, homeassistant-purpleair, ESPHome-Config)

[ptr727]

Found during a read-only PR-reviewer evaluation sweep on 2026-08-28 (unrelated to that sweep's
actual subject — Copilot/CodeRabbit/Qodo comparison — just surfaced by its open->close duration
metric). Filing here per pieter's request so it can be investigated properly.

Summary

Several Dependabot PRs across 3 fleet repos are stuck open for days despite auto-merge being
enabled and every status check reporting green, while same-day sibling PRs (often opened seconds
apart by the same Dependabot run) merge normally in under 2 minutes. mergeStateStatus reads
BLOCKED (or UNKNOWN) on the stuck ones even though mergeable: MERGEABLE and the
Merge dependabot pull request job itself reports conclusion: SUCCESS.

Affected PRs (as of 2026-08-28, still open)

Repo	PR	Opened	Age	mergeStateStatus	mergeable	Auto-merge enabled
PhotoCleaner	#81, #82	2026-08-21	~7.2 days	BLOCKED	MERGEABLE	yes
PhotoCleaner	#83, #84	2026-08-24	~4.2 days	BLOCKED	MERGEABLE	yes
homeassistant-purpleair	#252	2026-07-30	~29 days	BLOCKED	MERGEABLE	yes
homeassistant-purpleair	#279, #280	2026-08-19	~8.8 days	UNKNOWN	UNKNOWN	yes
homeassistant-purpleair	#283, #285	2026-08-24	~3.8 days	BLOCKED	MERGEABLE	yes
ESPHome-Config	#108	2026-08-24	~4.4 days	BLOCKED	MERGEABLE	yes

None of these have any review activity (reviews: []), no failing checks (every listed check is
COMPLETED/SUCCESS), and no merge conflicts. On PhotoCleaner #81/#82, for example, the
Merge bot pull request job / Merge dependabot pull request job itself reports
conclusion: SUCCESS, yet the PR sits BLOCKED — the same job succeeds identically on PRs from
the same repo that go on to merge in under 2 minutes (e.g. PhotoCleaner #79/#80, same-day
siblings). So whatever's blocking these isn't a check failure or a missing approval, and doesn't
correlate with anything visible in the PR's own check list.

Ask

Investigate why auto-merge isn't completing for this subset while identical-looking sibling PRs
(opened the same day, same workflow, same checks) merge normally. Candidate directions worth
ruling in/out (not verified — just what would produce this exact symptom): a required status
check registered under a name GitHub no longer sees reported for these specific runs, branch
protection's "require branches to be up to date" stalling because these particular PRs' base
branch advanced without a rebase being triggered, or a mergeStateStatus computation that's
stuck/stale rather than truly blocked. This affects auto-merge across at least 3 repos so it may
be a shared workflow/config issue rather than repo-specific.

[ptr727]

Investigation results

Checked statusCheckRollup, diffs, and workflow logs directly on all 9 listed PRs. The
premise doesn't hold for any of them: every one has a real, currently-failing required
check. mergeStateStatus: BLOCKED (or UNKNOWN) is GitHub computing correctly given that
failure, not a stale/stuck computation, a check-name mismatch, or a rebase-staleness problem —
I found no evidence of any of the candidate directions in the issue body. Five distinct root
causes, by repo:

PhotoCleaner #81-#84 ("Bump the nuget-deps group with 13 updates"): the group bump silently
includes csharpier itself (1.2.6 -> 1.3.0). The new csharpier version reformats raw string
literals differently, so dotnet csharpier check . now flags pre-existing, previously-
compliant code (Database.cs) that the bump never touched — real failure, Lint sources job
and Unit test job both FAILURE, Check pull request workflow status job FAILURE. This holds
the other 12 unrelated, harmless updates in the same PR hostage. Fixed at the template level in
#1062 (excludes the fleet's lint/format toolchain packages from the catch-all Dependabot
group) — that only helps future grouped bumps; these 4 PRs still need a manual
reformat-and-push, or PhotoCleaner adopting #1062's config via its own resync.

homeassistant-purpleair #283/#285 ("bump ruff from 0.15.22 to 0.16.4"): same self-bump
category, but not a grouping/hostage problem — purpleair's pip ecosystem has no groups:
block, so this is already a standalone PR. The newer ruff's stricter rules trip on existing
code (Ruff job FAILURE). Needs a ruff-driven cleanup/fix pass in that repo.

homeassistant-purpleair #252 (29 days old, "Bump HA test matrix (stable: 2026.8.3, beta:
2026.9.0b0)"): a genuine Home Assistant compat break — Pyright job and multiple pytest job
entries FAILURE against the newer HA release. Correctly blocked; needs real code fixes, not a
merge-mechanism fix. Worth noting as the one that's been silently stuck the longest with zero
visibility (no comment, no label — just sitting).

homeassistant-purpleair #279/#280 ("bump ghcr.io/devcontainers/features/github-cli from
1.1.0 to 1.1.1"): the devcontainers ecosystem bump regenerates .devcontainer-lock.json, and
the regenerated file doesn't conform to the repo's own EOL/editorconfig rule (Docs lint job:
"Not all lines have the correct end of line character"). Dependabot's own lockfile
regeneration doesn't respect the repo's configured line-ending convention here.

ESPHome-Config #108 ("Bump the actions-deps group with 4 updates"): all 4 updates are
ptr727/ProjectTemplate reusable-workflow SHA re-pins (2.0.380 -> 2.0.416), no unrelated
third-party actions bundled in — so not a hostage/grouping case either. The newer pinned
repo_gate.py now enforces *.bat/*.cmd -> CRLF in .editorconfig, and ESPHome-Config's
.editorconfig hasn't been resynced for the fleet's LF rollout yet. This is a known, already
-tracked gap: ESPHome-Config is an unchecked line item in docs/eol-lf-rollout.md, not a new
problem.

Recommendation

Re-scope rather than close — #1-#4 remain real, open work in their own repos (only #1's
template-level cause has a fix so far, in #1062), and #5 is better tracked via the existing
docs/eol-lf-rollout.md rollout than as a new item here.