GeezerVison

All reactions

lelia temporarily deployed to socket-firewall September 2, 2026 22:47 — with GitHub Actions Inactive

Eric Hibbs (flowstate) left a comment

[agent] Verified the bug mechanically rather than just trusting the description: on main, SEVERITY_ORDER/SEVERITY_EMOJI/severity_counts all key on 'medium' with no 'middle' entry, so a mid-severity finding (which is what the API actually sends, matching the SDK's SocketIssueSeverity) misses the count, defaults to sort order 4 (below 'low' at 3), and gets the fallback emoji -- exactly the three symptoms described. The one-line normalization at the read site matches the pattern already used in Messages.map_socket_severity_to_gitlab. All 7 new regression tests pass.

Approving the fix itself. The socketdev 3.6.0 version-bump checklist in the description is correctly left undone and unchecked pending that release, so this stays unmerged until then -- nothing for me to act on there.

Every severity lookup in the Slack reachability formatter is keyed on "medium",
but "middle" is what the API sends. A mid-severity finding missed all of them
at once: uncounted in the summary, excluded from total_findings so the "and N
more" count can go negative, and sorted at the default order of 4 -- below
"low" -- so it was truncated out of the message first.

Normalized at the point the alert is read rather than by adding a parallel key
to each dict, so one canonical spelling flows downstream. The GitLab severity
map and the PR comment path already accept both forms; this formatter did not.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

Unblocks the pin now that 3.6.0 is on PyPI. SocketPURL_Type gained ten
members -- alpm, chrome, clawhub, edge-extension, firefox-extension, qpkg,
socket, swid, vscode and vscode-extension -- and removed none, so artifacts
of those types stop falling back to "unknown".

No other CLI change is needed: none of the SDK's enum types are imported
here, and every severity and type lookup already has a default, so the new
members cannot reach an unguarded branch.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

lelia temporarily deployed to socket-firewall September 9, 2026 22:57 — with GitHub Actions Inactive

Copy link

Copy Markdown

Copy link

Copy Markdown

The check required the PR version to exceed both main and PyPI. Comparing
against main forbids the legitimate case where several PRs ship under one
unreleased version: the first bumps main, and the rest ride it without
bumping again so they stay under a single changelog header. Every such PR
failed, and the only way to green it was a throwaway bump that would strand
a changelog header on a version that never ships.

PyPI is now the floor, since the real invariant is that a release cannot
reuse a published version. Main is still a floor in the one direction that
matters: a PR may leave the version alone or move it forwards, never back.
Every genuine failure the old check caught -- forgetting to bump, reusing a
published version, branching from a stale base -- still fails.

Also added this workflow to its own paths filter so a change to the check is
exercised by the PR that makes it.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

lelia temporarily deployed to socket-firewall September 9, 2026 23:02 — with GitHub Actions Inactive

The version lives as two hand-maintained literals with nothing deriving one
from the other: pyproject.toml is what gets published, and __init__.py is
what the CLI reports as its User-Agent. Every comparison in this job read
only __init__.py, so bumping that alone passed the check and then published
under the old number -- surfacing late, as twine rejecting an existing file,
after the merge.

Both are now required to match before any other comparison runs. uv.lock
carries a third copy, but uv derives it and `uv lock --locked` in
python-tests already fails when it drifts, so it needs no check here.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

lelia temporarily deployed to socket-firewall September 9, 2026 23:35 — with GitHub Actions Inactive