bug: tea CLI 0.11.1 silently no-ops on tea pr comment / tea issue comment — false-success durable-comment writes fleet-wide
#865
Assignees
jason.woltje
Clear assignees
jason.woltje
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: mosaicstack/stack#865
Reference in New Issue
Block a user
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?
Found by: uc-rev-2, surfaced via uc-lead (uconnect-58) during a #2941/PR#2941 gate-integrity investigation, 2026-07-21.
Root cause:
tea0.11.1 has nocommentsubcommand undertea prortea issue— the correct invocation is the top-leveltea comment <issue/pr index> <body> [--repo ...] [--login ...](confirmed viatea comment --help).tea pr --help/tea issue --helplist nocommentaction at all.When framework scripts call the non-existent subcommand form,
tea's CLI parser does not error — it silently falls through to a listing/no-op behavior and exits 0, so callers see success (echo "Added comment...") even though nothing was posted. This is a false-success write: any code path that trusted the exit code (rather than independently re-fetching the comment via API) would believe a durable Gitea attestation exists when it does not.Affected files (confirmed via grep, same pattern):
packages/mosaic/framework/tools/git/pr-review.sh—commentaction, line ~104:tea pr comment "$PR_NUMBER" "$COMMENT" $(get_gitea_repo_args)packages/mosaic/framework/tools/git/issue-comment.sh— line ~64:tea issue comment "$ISSUE_NUMBER" "$COMMENT" --repo "$REPO_SLUG" --login "$GITEA_LOGIN_NAME"(
approve/request-changes/reopen/closeactions in sibling scripts use validtea pr/tea issuesubcommands pertea pr --help— those are NOT affected, only thecommentaction.)Suggested fix:
tea comment "$PR_NUMBER" "$COMMENT" $(get_gitea_repo_args)(drop thepr/issuesub-noun).tea comment --output jsonor a direct API GET, confirm the body/timestamp matches) before echoing success — don't trusttea's exit code alone, since this incident shows it can be 0 on a no-op.Blast radius / why this matters beyond uconnect: these are shared framework tools (
~/.config/mosaic/tools/deployed fleet-wide) used by every team-lead/reviewer role across all Mosaic-managed repos, not just usc/uconnect. Any historical "posted a durable comment" claim that relied on these two scripts' exit code alone (rather than an independent API re-check) should be treated as unverified until spot-checked. In the originating incident, a retroactive API check found the specific comment in question DID land (comment 27852, uconnect#2941) and an earlier one on #2936 (comment 27833) was also confirmed genuine — so this is not yet known to have caused an actual missed-attestation, but the false-success behavior itself is confirmed and reproducible.Repro:
tea pr --helpandtea issue --help(v0.11.1) list nocommentsubcommand;tea comment --helpshows the correct top-level command.Filing for MS-LEAD / framework-maintainer triage rather than pushing a same-turn fix —
/src/mosaic-stackcheckout is in detached HEAD (15 behind origin/main), not set up for a drive-by commit right now.Second live recurrence confirmed, independent of the original report: uc-rev-1 (a different reviewer instance, uc/uconnect PR#2939) hit the same false-success write via the broken wrapper — its first Re-CODE GO attempt after PR#2939's head advanced to
29c03c4e2dednever actually posted (confirmed absent via direct API query, only the automated triage comment existed). uc-lead caught it via the same direct-API-verify discipline established after the first incident, told uc-rev-1 to repost via thetea comment <index> <body> --repo ... --login ...workaround, and the repost landed genuinely (comment 27855, verified). Raises confidence this is a systemic/reliable reproduction (2-for-2 reviewer instances hitting it under normal use, not an edge case) rather than a one-off — bumping suggested priority. Workaround (tea commenttop-level form) is holding up as the correct fix in both live recurrences.Data point #3 (live, 2026-07-21T19:0xZ): uc-rev-2 hit the same silent no-op again on usc/uconnect PR #2942 (#2938) — relayed a CODE GO with 0 comments actually present via API. Reposted via the tea-comment workaround (comment 27868, confirmed durable). This is now 3 recurrences across 2 distinct reviewer instances (uc-rev-1, uc-rev-2, uc-secrev previously) in a single session — confirms this is a systemic, not edge-case, failure mode of pr-review.sh/issue-comment.sh comment mode. uc-lead (uconnect-58) is broadcasting standing fleet guidance to skip pr-review.sh/issue-comment.sh comment mode entirely and always post via top-level
tea comment <id> <body> --repo ... --login ...+ a post-write API read-back verification, until this lands upstream. I have endorsed that guidance rather than holding for the framework fix, given the recurrence rate. Still deferred to MS-LEAD/framework maintainers for the actual code fix in packages/mosaic/framework/tools/git/{pr-review,issue-comment}.sh.