mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

issue-create.sh silently drops labels/milestone on the Gitea API fallback and exits 0 #937

New Issue
Open
opened 2026-07-27 14:09:05 +00:00 by Ghost · 0 comments
Ghost commented 2026-07-27 14:09:05 +00:00
Copy Link
Copy Source

tools/git/issue-create.sh silently discards --labels and --milestone when it falls back to the Gitea REST API, and exits 0, so the caller believes the issue was created as specified.

Behaviour

When tea authenticated-user validation fails, the script warns and falls back to the Gitea API. That fallback path applies title and body only. The warning names the limitation:

Warning: Tea authenticated-user validation failed (possible stale user/login); trying Gitea API fallback...
Warning: API fallback currently applies title/body only; labels/milestone require authenticated tea setup.

...but the command still returns exit 0 with a fully-populated issue JSON, so any caller checking the exit status — or the returned issue object's presence — concludes success.

Why this matters more than a cosmetic gap

Labels are frequently the only retrieval path for an issue class. An issue filed unlabelled is not merely untidy; it is invisible to every label-scoped sweep. A security finding filed without its security label will not appear in a security triage query, and nothing in the output tells the filer that happened. The failure is silent at exactly the moment the metadata mattered.

This is the general shape of "an artifact whose name claims an outcome its execution did not deliver": the command reports success for a partially-completed operation.

Observed

Reproduced repeatedly in a single session across two different repositories on the same Gitea host — so it is a systemic property of the fallback path, not a per-repo permissions quirk. Each time, the issue was created and the labels were absent; each time the caller had to notice and re-attach labels through a separate API call.

Fix candidates

  1. Preferred — complete the operation. The fallback already holds a working API token; apply labels in a follow-up POST /repos/{owner}/{repo}/issues/{index}/labels (and set the milestone via PATCH). Label IDs resolve from GET /repos/{owner}/{repo}/labels. The fallback is then feature-equivalent, and the warning becomes unnecessary.
  2. Minimum — fail loudly. If labels/milestone were requested and cannot be applied, exit non-zero with the created issue number in the message, so the caller knows the issue exists but is incompletely specified and can finish the job. Silent partial success is the part that must go.

Option 1 is strictly better; option 2 is the floor. What must not remain is exit 0 on a request that was only partly carried out.

`tools/git/issue-create.sh` silently discards `--labels` and `--milestone` when it falls back to the Gitea REST API, and exits **0**, so the caller believes the issue was created as specified. ## Behaviour When tea authenticated-user validation fails, the script warns and falls back to the Gitea API. That fallback path applies **title and body only**. The warning names the limitation: ``` Warning: Tea authenticated-user validation failed (possible stale user/login); trying Gitea API fallback... Warning: API fallback currently applies title/body only; labels/milestone require authenticated tea setup. ``` ...but the command still returns exit 0 with a fully-populated issue JSON, so any caller checking the exit status — or the returned issue object's presence — concludes success. ## Why this matters more than a cosmetic gap Labels are frequently the **only** retrieval path for an issue class. An issue filed unlabelled is not merely untidy; it is **invisible to every label-scoped sweep**. A security finding filed without its security label will not appear in a security triage query, and nothing in the output tells the filer that happened. The failure is silent at exactly the moment the metadata mattered. This is the general shape of "an artifact whose name claims an outcome its execution did not deliver": the command reports success for a partially-completed operation. ## Observed Reproduced repeatedly in a single session across two different repositories on the same Gitea host — so it is a systemic property of the fallback path, not a per-repo permissions quirk. Each time, the issue was created and the labels were absent; each time the caller had to notice and re-attach labels through a separate API call. ## Fix candidates 1. **Preferred — complete the operation.** The fallback already holds a working API token; apply labels in a follow-up `POST /repos/{owner}/{repo}/issues/{index}/labels` (and set the milestone via `PATCH`). Label IDs resolve from `GET /repos/{owner}/{repo}/labels`. The fallback is then feature-equivalent, and the warning becomes unnecessary. 2. **Minimum — fail loudly.** If labels/milestone were requested and cannot be applied, exit **non-zero** with the created issue number in the message, so the caller knows the issue exists but is incompletely specified and can finish the job. Silent partial success is the part that must go. Option 1 is strictly better; option 2 is the floor. What must not remain is exit 0 on a request that was only partly carried out.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#937