Open security alerts rose on this board

[iderex]

Open security alerts on this board are higher than they were at the previous reading, or carry a rule id that reading did not hold.

kind	rule	was	now
code-scanning	cs/linq/missed-select	0	2
code-scanning	cs/path-combine	0	1
code-scanning	cs/string-concatenation-in-loop	0	1

Every row is a count of open alerts grouped by rule id. The current state is read directly:

gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/code-scanning/alerts?state=open&per_page=100" --jq 'length'

What this is not

It is not a judgement of any alert. Nothing here reads a finding, weighs it, or says whether it is a true positive; the reading is a count of what the platform reports as open, grouped by rule id.

A count that falls produces no issue and no comment, so this body going quiet is not evidence that anything was fixed.

A kind that could not be read on a run contributes no count on that run and is named in that run's summary rather than passed over as a zero.

The sweep behind this is .github/workflows/fleet-alert-sweep.yml in iderex/wache, asked for by iderex/wache#31.

[iderex]

One of the three rows is at zero, and the other two are now readable as a wait rather than as a number somebody re-reads each round.

The cs/path-combine row is disposed of under #374, where the site, the predicate and the dismissal are read out. I am not repeating them here.

What the platform reports open now:

gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/code-scanning/alerts?state=open&per_page=100" \
  --jq '.[] | .number, .rule.id'
239
cs/linq/missed-select
238
cs/linq/missed-select
237
cs/string-concatenation-in-loop

Two rows left, and each is an open issue rather than an unread finding: cs/linq/missed-select is #373, cs/string-concatenation-in-loop is #375. Both are declared as blockers of this issue, so the relation resolves when they close:

gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/issues/372/dependencies/blocked_by" \
  --jq '[.[] | "#\(.number) [\(.state)]"] | join(", ")'
#373 [open], #375 [open]

The milestone is set to the one the two previous readings of this kind carry, #306 and #350, so this issue is counted where they were.

No second reader looked at this. The commands above are the evidence in place of one.

[iderex]

All three rows are at zero, and so is every other rule, read after the scan had been over the head of master.

The two rows that were open issues have closed. cs/linq/missed-select was #373 and cs/string-concatenation-in-loop was #375, and the relation this issue declared resolves with them:

gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/issues/372/dependencies/blocked_by" \
  --jq '[.[] | "#\(.number) [\(.state)]"] | join(", ")'
#373 [closed], #375 [closed]

The three alerts behind those two rows are fixed rather than dismissed, each read at its own number:

for n in 237 238 239; do
  gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/code-scanning/alerts/$n" \
    --jq '"\(.number)\t\(.rule.id)\t\(.state)\t\(.fixed_at)\t\(.most_recent_instance.location.path):\(.most_recent_instance.location.start_line)"'
done
237	cs/string-concatenation-in-loop	fixed	2026-09-07T04:07:31Z	Jellyfin.Plugin.MetadataSync.Tests/ReleaseVersionAgreementTests.cs:737
238	cs/linq/missed-select	fixed	2026-09-07T03:53:46Z	Jellyfin.Plugin.MetadataSync.Tests/ReleaseVersionAgreementTests.cs:616
239	cs/linq/missed-select	fixed	2026-09-07T03:53:46Z	Jellyfin.Plugin.MetadataSync.Tests/ReleaseVersionAgreementTests.cs:686

The cs/path-combine row went by dismissal under #374, which is closed, and dismissed is not repaired. Alert 240 carries won't fix at its own site, so reading this table falling to zero as four defects repaired would be the mistake the body warns against: three were repaired and one was judged.

gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/code-scanning/alerts/240" \
  --jq '"\(.number)\t\(.state)\t\(.dismissed_at)\t\(.dismissed_reason)"'
240	dismissed	2026-09-07T02:13:10Z	won't fix

The open set, read after the scan that ran over the current head. The run matters as much as the count, as #306 already said: a zero read before the scan had been over the head is a zero about a tree nobody analysed.

gh run list --repo Flowfin/jellyfin-plugin-metadata-sync --workflow scan-codeql.yaml --branch master --limit 1 \
  --json conclusion,headSha --jq '.[] | "\(.conclusion)\t\(.headSha[0:7])"'
success	753547b

gh api --paginate "repos/Flowfin/jellyfin-plugin-metadata-sync/code-scanning/alerts?state=open&per_page=100" --jq 'length'
0
gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/dependabot/alerts?state=open&per_page=100" --jq 'length'
0
gh api "repos/Flowfin/jellyfin-plugin-metadata-sync/secret-scanning/alerts?state=open&per_page=100" --jq 'length'
0

Nothing in the tree changed for this issue and no pull request belongs to it. I am taking the dependency label off because both issues it waited on have closed. The body asks for the count to come back rather than naming a done-condition in words. It is zero, so I am closing this.

No second reader looked at this. The commands above are the evidence in place of one.