Dependabot nuget-deps PRs stuck BLOCKED: csharpier self-bump breaks existing formatting

[ptr727]

Symptom

PRs #81, #82, #83, #84 (the daily nuget-deps group bumps) are stuck mergeStateStatus: BLOCKED
despite auto-merge being enabled, for days. mergeable: MERGEABLE, no review activity, no merge
conflicts — but Validate sources job / Lint sources job and Validate sources job / Unit test job
report FAILURE on all four, and the aggregate Check pull request workflow status job FAILURE is
what actually blocks the merge.

Root cause

The nuget-deps group bundles every NuGet update together (patterns: ["*"]), including
csharpier itself: PR #81 bumps it 1.2.6 -> 1.3.0. The newer csharpier version reformats raw
string literals differently, so dotnet csharpier check . now flags pre-existing,
previously-compliant code (PhotoCleaner/Database.cs) that the dependency bump never touched:

Error ./PhotoCleaner/Database.cs - Was not formatted.
  ----------------------------- Expected: Around Line 148 -----------------------------
                  cmd.CommandText = """
                      INSERT OR IGNORE INTO files (...)
  ----------------------------- Actual: Around Line 148 -----------------------------
                  cmd.CommandText = """
                  INSERT OR IGNORE INTO files (...)

Because csharpier rides along in the same grouped PR as 12 unrelated, harmless updates, its
self-inflicted lint failure blocks all of them together.

How to get unstuck

1. Reformat once, as its own commit, with the new csharpier version:

   dotnet csharpier format .
   

   Land this on develop (and main, once promoted) as a normal maintainer commit — not through
   one of the stuck PRs.
2. Close Bump the nuget-deps group with 13 updates #81-build(deps): Bump the actions-deps group with 4 updates #84 once the reformat commit lands. Dependabot's next daily run reopens a fresh
   nuget-deps PR for whatever's still outdated; it will no longer include a csharpier bump (already
   current) and will pass lint (the repo is already reformatted to match it).
3. Prevent recurrence: adopt ptr727/ProjectTemplate's updated
   catalog/snippets/configs/dependabot.yml
   (from ProjectTemplate#1062) via this
   repo's next fleet resync. It excludes csharpier, husky, and dotnet-outdated-tool from the
   nuget-deps group, so a future toolchain self-bump gets its own individual PR instead of
   blocking the whole group again.

Filed as part of investigating ProjectTemplate#1055.

[ptr727]

Status update

The immediate symptom is resolved: #81 and #82 are merged (2026-08-29), CI is green — Database.cs was reformatted for the current csharpier version as part of #81. #83/#84 are closed (dependabot's next run superseded them, as predicted above).

Recurrence prevention: reconsidered, not implementing the grouping-exclusion approach

This issue's step 3 recommended excluding csharpier/husky/dotnet-outdated-tool from the nuget-deps dependabot group. On review, that approach is declined: it would make the next toolchain self-bump merge cleanly on its own, which means it stops alerting anyone that a reformat is actually needed — trading a visible, blocking failure for a silent one. That's the opposite of what's wanted here.

A second option — a CI job that auto-reformats and pushes a fixup commit directly onto the dependabot PR's own branch to make it pass — is also ruled out: pushing any commit onto a Dependabot/App PR branch disables auto-merge fleet-wide, and it never re-arms itself. That's a known incident on this fleet, not a hypothetical.

Recommended durable fix, not yet implemented: land a normal, separate PR to develop that pre-emptively reformats the codebase for the next csharpier version ahead of the dependabot bump — an ordinary PR through normal review/merge, no bot-branch commit involved. This keeps the dependabot PR red/blocked exactly when a reformat is actually outstanding (so it still visibly demands manual attention), while letting a maintainer clear that block proactively via a normal PR instead of hand-fixing a stuck bot PR after the fact.

Leaving this issue open — no code change has been made toward this yet.