Found by the repo-wide /code-tidying:batch-simplify sweep (group G67). Reported, not fixed — the sweep is behavior-preserving.
What happens
plugins/work-items/tools/work-item-tracker/adapters/gitea/create-item.sh:124 reads:
(($(jq 'length' <<<"$WIT_GITEA_BODY") < WIT_GITEA_PAGE_SIZE)) && break
Unlike every sibling jq 'length' call in this adapter, this one has neither 2>/dev/null nor a numeric fallback. The siblings that do:
create-item.sh:118create-item.sh:145common.sh:463list-items.sh:79
Why it matters
On a non-array body, jq errors and the command substitution yields the empty string. Bash then evaluates (( < 50 )), which is an arithmetic syntax error: it prints to stderr, returns 1, and — because this is the && side of a short-circuit — the break never fires. The paging loop continues rather than stopping.
Two consequences: extra API requests against Gitea for pages the adapter has already decided it cannot parse, and a wrong truncation verdict, since the loop's exit condition is what determines whether the label set was fully walked. A stderr arithmetic error is also a poor diagnostic for "the API returned something that is not a list".
Suggested direction
Match the sibling form already used four times in the same adapter — 2>/dev/null plus a numeric fallback — so a malformed page produces a definite number rather than an empty expansion. Worth deciding deliberately whether the right fallback is 0 (treat as a short page, break, report truncation) or a loud failure, since the two differ in whether a malformed page silently ends the walk or aborts the operation. The surrounding code's fail-loud posture on checked reads suggests the latter deserves consideration.
Fixing this changes behavior on the malformed-response path, which is why the sweep left it alone.
Found by the repo-wide
/code-tidying:batch-simplifysweep (group G67). Reported, not fixed — the sweep is behavior-preserving.What happens
plugins/work-items/tools/work-item-tracker/adapters/gitea/create-item.sh:124reads:Unlike every sibling
jq 'length'call in this adapter, this one has neither2>/dev/nullnor a numeric fallback. The siblings that do:create-item.sh:118create-item.sh:145common.sh:463list-items.sh:79Why it matters
On a non-array body, jq errors and the command substitution yields the empty string. Bash then evaluates
(( < 50 )), which is an arithmetic syntax error: it prints to stderr, returns 1, and — because this is the&&side of a short-circuit — thebreaknever fires. The paging loop continues rather than stopping.Two consequences: extra API requests against Gitea for pages the adapter has already decided it cannot parse, and a wrong truncation verdict, since the loop's exit condition is what determines whether the label set was fully walked. A stderr arithmetic error is also a poor diagnostic for "the API returned something that is not a list".
Suggested direction
Match the sibling form already used four times in the same adapter —
2>/dev/nullplus a numeric fallback — so a malformed page produces a definite number rather than an empty expansion. Worth deciding deliberately whether the right fallback is 0 (treat as a short page, break, report truncation) or a loud failure, since the two differ in whether a malformed page silently ends the walk or aborts the operation. The surrounding code's fail-loud posture on checked reads suggests the latter deserves consideration.Fixing this changes behavior on the malformed-response path, which is why the sweep left it alone.