Default branch: Required check names did not succeed

[github-actions]

The newest completed run of Required check names on main concluded failure.

https://github.com/Flowfin/site/actions/runs/33310806663

Read at 2026-08-30T12:11:20Z, by https://github.com/Flowfin/site/actions/runs/33387615752.

This entry is rewritten while that stays true, and closed once the newest completed run of that workflow on main succeeds. Nothing re-runs the job: a re-run that happens to pass turns a defect into an intermittent one.

Renaming this entry produces a second one on the next pass, because the title is what identifies it.

[iderex]

The newest completed run does conclude failure, and it is the state the
workflow is written to end in rather than a defect in it. Nothing in this
repository can turn it green.

gh run list --repo Flowfin/site --workflow required-check-names.yml \
  --branch main --limit 1 --json databaseId,conclusion,headSha \
  --jq '.[] | "\(.databaseId)\t\(.conclusion)\t\(.headSha)"'
31933433043	failure	441b56b3893565bde005ade8eb8d78000f3c7458

The run reads both lists and reaches the third of the four states its script
names as not a pass:

gh run view 31933433043 --repo Flowfin/site --log \
  | grep -E 'require no status check|What ends this state|exit code 1' \
  | sed 's/^[^\t]*\t[^\t]*\t//'
2026-08-16T07:15:58.4654262Z The rules on Flowfin/site@main require no status check, so there is no name for a reported one to satisfy and nothing was compared.
2026-08-16T07:15:58.4656293Z What ends this state is a required status check on that branch. Until then this run has nothing to say about whether the two lists agree, and it says that rather than passing.
2026-08-16T07:15:58.4687562Z ##[error]Process completed with exit code 1.

The branch it read requires none:

gh api repos/Flowfin/site/rules/branches/main \
  --jq '[.[] | select(.type=="required_status_checks") | .parameters.required_status_checks[].context]'
[]
gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request"]

The reported side of the comparison is not what is missing. Sixteen names
reported on the head of the pull request that run took as its subject:

gh api repos/Flowfin/site/commits/93006f07cc802ae34d1878a523c10aa8f9f7494d/check-runs \
  --paginate --jq '.check_runs[].name' | sort -u | wc -l
16

All commands run 2026-08-16. The workflow says the same thing about itself at
the top of its own file:

gh api repos/Flowfin/site/contents/.github/workflows/required-check-names.yml \
  --jq '.content' | base64 -d | sed -n '15,18p'
# A run that compared nothing does not pass. The rules on this repository's
# default branch require no status check today, so a scheduled run reds and says
# so until one is required. That is the same shape the freshness comparisons in
# this plan use, and it is why the failure watchdog beside this file may open an

So what ends this entry is a required status check named on main, which is
#47, and that is a change to the rules on the branch rather than a change to
this tree. Nothing here re-runs the job, because a re-run reaches the same
state for the same reason.

[iderex]

Why blocked-on-another-issue came off this entry

The reading of this board's blocked issues refused this entry and reddened on it:

go run . blockers
  #135: NAMES NO ISSUE, it carries blocked-on-another-issue and its body has no number to resolve
23 issue(s) read, 1 naming no issue, 0 no longer blocked, 0 unresolved.
blockers: 1 name no issue by number
exit status 1

Run 2026-08-23 at 8a45538. That is the verdict the run on the default branch
reached as well, so the board carried a second red workflow for it:

https://github.com/Flowfin/site/actions/runs/32624231893

No edit to this body could have repaired that. The body here is written by another
workflow and rewritten every time it looks, for as long as the run it reports stays
red:

grep -n 'issue edit "$number" --repo "$REPO" --body "$body"' .github/workflows/failure-watchdog.yml
151:                    gh issue edit "$number" --repo "$REPO" --body "$body" </dev/null >/dev/null

so a number written into it survives until the next look and no longer. The package
behind the reading says the same thing from the other side:

grep -n 'no later run will do better' internal/blockers/blockers.go
16:// refused: nothing can be resolved for it and no later run will do better. An

Both run 2026-08-23 at 8a45538.

What this entry waits for

A required status check named on the default branch, which is a repository setting,
and this entry already carries the label for one. The branch requires none:

gh api repos/Flowfin/site/rulesets/20572614 --jq '[.rules[].type]'
["deletion","non_fast_forward","pull_request"]

Run 2026-08-23.

Reading it instead as waiting on #47 declares a cycle rather than a dependency,
because #47 names this entry among its own:

go run . blockers | grep '^  #47:'
  #47: blocked, waiting on #12 (open issue), #18 (open issue), #44 (open issue), #62 (open issue), #135 (open issue)

Run 2026-08-23 at 8a45538. The two wait on one setting. Neither waits on the
other's work.

What moved and what did not

The label, and nothing else. This entry keeps ci, keeps
blocked-on-a-repository-setting, keeps its assignee and its milestone, and any
count that subtracts a blocked-on- prefix still subtracts it, so nothing reads it
as available work.

The reading is green on the tree and on the default branch:

go run . blockers
22 issue(s) read, 0 naming no issue, 0 no longer blocked, 0 unresolved.
exit=0

Run 2026-08-23 at 8a45538, and

https://github.com/Flowfin/site/actions/runs/32635041428
completed success

read 2026-08-23. That run is a dispatch of the same workflow rather than a fresh
verdict on a changed tree, because what the verb reads is the tracker and the
tracker is what changed.

Nothing in this entry's own condition is met by any of it. Required check names
on the default branch still concludes failure for the reason already read here,
and what ends that is unchanged.