ops forgejo issue create silently no-ops on a redirecting repo (POST->GET downgrade reads as success) #160
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Summary
coily ops forgejo issue createsilently creates nothing when--reponames a repo that 302-redirects (e.g. the pre-split org namecoilysiren/<repo>now living undercoilyco-flight-deck/<repo>). The redirect downgrades the POST to a GET, so the issues-list endpoint answersHTTP 200with a JSON array of existing issues. coily treats the 2xx as success and prints the array, looking exactly like a successful create while nothing was created.A create verb that silently no-ops is a real hazard - the operator (or an agent) believes the issue was filed and moves on.
Reproduction
Observed 2026-05-30 on kai-server while filing infra issues:
Retargeting the same call at the canonical owner worked and returned the created issue:
Root cause
Forgejo issues a 302 (not 307/308) for the moved repo. HTTP clients downgrade POST->GET on 302 by default. The POST body is dropped and the request lands on
GET /repos/{owner}/{repo}/issues(list), which returns 200 + array. coily's create path keys success off the 2xx status without asserting the response is a created-issue object.Fixes (any/all)
number. Treat 200, or an array body, or a missingnumber, as failure - exit non-zero with a clear message naming the redirect.Fix (1) alone closes the silent-failure hazard; (2)/(3) improve the message.
Impact
Any coily forgejo write verb (issue/label/milestone/release create, issue edit/comment/close) routed at a redirecting repo name is suspect, not just
issue create. Worth auditing the wholeops forgejowrite surface for the same 2xx-means-success assumption.Found during the 2026-05-30 kai-server crash investigation while filing follow-up issues.