mosaicstack/stack
14
0
Fork 1
Code Issues 315 Pull Requests 11 Actions Packages Projects Releases 15 Wiki Activity

issue-view.sh cannot show issue comments (4 defects: worktreeconfig, JSON fallback, missing --comments, wrong diagnosis) #1357

New Issue
Closed
opened 2026-08-21 20:43:48 +00:00 by fred · 0 comments
fred commented 2026-08-21 20:43:48 +00:00
Collaborator
Copy Link
Copy Source

issue-view.sh cannot show issue comments. An agent reading an issue through the wrapper sees the issue body and nothing else, with no indication that comments exist. This is how a maintainer's comment on an issue gets missed by the agent working that issue.

Four separate defects, each measured below with a control.

F1 — tea is unusable inside any repo with extensions.worktreeconfig=true

$ cd <repo with worktreeconfig>
$ tea issue 1356 --repo mosaicstack/stack --login <login> --comments
Error: core.repositoryformatversion does not support extension: worktreeconfig
rc=1

Control, same command, cwd not a repo:

$ cd /tmp
$ tea issue 1356 --repo mosaicstack/stack --login <login> --comments
rc=0   (issue + comments rendered)

An explicit --repo does not help: tea still reads the cwd's git config and dies before it uses the flag. git config --get extensions.worktreeconfig is true and core.repositoryformatversion is 1 in the affected repo — a valid modern git config that tea's vendored git library rejects.

Consequence: in an affected repo, every tea-path git wrapper silently degrades to its API fallback.

F2 — the API fallback prints raw JSON, and carries no comment bodies

When the tea path fails, issue-view.sh falls back to the REST API and dumps the raw issue JSON (67 lines for one issue). That JSON has "comments": <count> — a number, not the comments. So the comment bodies are unreachable on the fallback path by construction, and the count is buried in JSON rather than surfaced.

F3 — the wrapper never passes --comments

issue-view.sh:70 calls:

tea issue "$ISSUE_NUMBER" $(get_gitea_repo_args)

grep -c comment issue-view.sh → 0. Both tea issue and tea issues accept --comments. tea's own help says the flag "will prompt if not provided & run interactively" — non-interactively it just omits comments silently, which is the worst of the three possible behaviors. So even in a repo where F1 does not apply, comments are never shown.

F4 — the fallback prints a confidently wrong diagnosis

On the F1 failure the wrapper emits a multi-line NOTE: ... usually means a REVOKED OR STALE TOKEN banner. The token is fine; the failure is a git config extension. The banner sends the reader to re-register logins and rotate credentials for a problem that has nothing to do with credentials. A diagnostic that names a cause it has not checked is worse than no diagnostic.

Suggested remediation

  1. Pass --comments on the tea path (F3). Optionally gate behind a flag, but the default should show them: an agent reading an issue needs the thread, not just the opening post.
  2. On the API fallback, fetch /issues/{n}/comments and render body + comments as text, not raw JSON (F2).
  3. Make the tea path robust to F1 rather than silently degrading — either run tea from a cwd it can parse when --repo is explicit, or detect the repositoryformatversion error and say so.
  4. Replace the stale-token banner with one that reports the actual stderr from tea, and only names a credential cause when the error is a credential error (F4).

Verification for the fix

The regression test must assert on a real comment body appearing in the output, in both the tea path and the API path, and must include the negative control (an issue with no comments does not print a comment section). A test that greps for the word "comment" passes on the issue title — that instrument was tried here and gave an inverted reading.

`issue-view.sh` cannot show issue comments. An agent reading an issue through the wrapper sees the issue body and nothing else, with no indication that comments exist. This is how a maintainer's comment on an issue gets missed by the agent working that issue. Four separate defects, each measured below with a control. ## F1 — tea is unusable inside any repo with `extensions.worktreeconfig=true` ``` $ cd <repo with worktreeconfig> $ tea issue 1356 --repo mosaicstack/stack --login <login> --comments Error: core.repositoryformatversion does not support extension: worktreeconfig rc=1 ``` Control, same command, cwd not a repo: ``` $ cd /tmp $ tea issue 1356 --repo mosaicstack/stack --login <login> --comments rc=0 (issue + comments rendered) ``` An explicit `--repo` does not help: tea still reads the cwd's git config and dies before it uses the flag. `git config --get extensions.worktreeconfig` is `true` and `core.repositoryformatversion` is `1` in the affected repo — a valid modern git config that tea's vendored git library rejects. Consequence: in an affected repo, *every* tea-path git wrapper silently degrades to its API fallback. ## F2 — the API fallback prints raw JSON, and carries no comment bodies When the tea path fails, `issue-view.sh` falls back to the REST API and dumps the raw issue JSON (67 lines for one issue). That JSON has `"comments": <count>` — a number, not the comments. So the comment bodies are unreachable on the fallback path by construction, and the count is buried in JSON rather than surfaced. ## F3 — the wrapper never passes `--comments` `issue-view.sh:70` calls: ``` tea issue "$ISSUE_NUMBER" $(get_gitea_repo_args) ``` `grep -c comment issue-view.sh` → 0. Both `tea issue` and `tea issues` accept `--comments`. tea's own help says the flag "will prompt if not provided & run interactively" — non-interactively it just omits comments silently, which is the worst of the three possible behaviors. So even in a repo where F1 does not apply, comments are never shown. ## F4 — the fallback prints a confidently wrong diagnosis On the F1 failure the wrapper emits a multi-line `NOTE: ... usually means a REVOKED OR STALE TOKEN` banner. The token is fine; the failure is a git config extension. The banner sends the reader to re-register logins and rotate credentials for a problem that has nothing to do with credentials. A diagnostic that names a cause it has not checked is worse than no diagnostic. ## Suggested remediation 1. Pass `--comments` on the tea path (F3). Optionally gate behind a flag, but the default should show them: an agent reading an issue needs the thread, not just the opening post. 2. On the API fallback, fetch `/issues/{n}/comments` and render body + comments as text, not raw JSON (F2). 3. Make the tea path robust to F1 rather than silently degrading — either run tea from a cwd it can parse when `--repo` is explicit, or detect the `repositoryformatversion` error and say so. 4. Replace the stale-token banner with one that reports the actual stderr from tea, and only names a credential cause when the error is a credential error (F4). ## Verification for the fix The regression test must assert on a real comment body appearing in the output, in both the tea path and the API path, and must include the negative control (an issue with no comments does not print a comment section). A test that greps for the word "comment" passes on the issue *title* — that instrument was tried here and gave an inverted reading.
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-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#1357