Fix cve-watch issue creation (422 on string labels) #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/cve-watch-label-ids"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The last cve-watch bug. With #1 the 403 was cleared (token scope + dropping the server-side
q=search) and the API error body is now surfaced — which revealed the real cause of the remaining failure:Forgejo's create-issue API expects
labelsas an array of integer label IDs, not names (a Gitea/Forgejo divergence from GitHub). The payload sent["cve-watch","upstream"](names) → 422.Fix: resolve the desired label names to IDs from the repo's existing labels (
GET /labels) and post the matched IDs. Best-effort — a failed lookup or a not-yet-created label files the issue without that label rather than blocking, so issue creation never depends on label state.Verified: yamllint clean; the resolution + payload jq produce integer IDs when the labels exist and
[]when they don't (Forgejo accepts an emptylabelsarray).Follow-ups (not blocking)
cve-watch/upstreamlabels in the repo once (Issues → Labels) if you want them auto-applied; otherwise issues file unlabeled.new=truewas a genuine new-upstream detection (the F8 normalization from #1 is working, so it's not the old hourly false-positive). Once this merges, the next hourly run files the real tracking issue — kicking off the normal response flow (verify upstream signature → push matching tag → build).🤖 Generated with Claude Code
With the 403 cleared (token scope + dropped q= search) and the error body now surfaced, the real cause showed itself: Forgejo's create-issue API expects `labels` as an array of integer label IDs, not names (a Gitea/Forgejo divergence from GitHub). Posting names returned: 422 "cannot unmarshal string into Go struct field CreateIssueOption.labels of type int64" Resolve the desired names to IDs from the repo's existing labels (GET /labels) and post the matched IDs; best-effort, so a failed lookup or a not-yet-created label files the issue WITHOUT that label rather than blocking. (Create the `cve-watch` / `upstream` labels in the repo once for them to be auto-applied.) Note: this run's new=true was a genuine new-upstream detection, not the old hourly false-positive — the F8 normalization from #1 is working. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>