mosaicstack/stack
1
0
Fork 1
Code Issues 200 Pull Requests 10 Actions Packages Projects Releases 15 Wiki Activity

detect-platform.sh: add a diagnostic for tea's misleading user does not exist error (stale token, not a missing account) #1082

New Issue
Closed
opened 2026-08-06 20:33:40 +00:00 by Mos · 0 comments
Mos commented 2026-08-06 20:33:40 +00:00
Contributor
Copy Link
Copy Source

Summary

When a tea call fails with user does not exist [uid: 0, name: ], the message is misleading: it almost always means a revoked or stale token, not a missing account. tea login stores its own copy of the token, so rotating the credential store does not update it.

This costs real debugging time — the error points at the account, the cause is the cached credential.

Proposal

Add a small diagnostic helper in tools/git/detect-platform.sh, invoked from the existing tea-failure fallback paths in issue-view.sh, issue-create.sh and pr-create.sh:

explain_tea_user_does_not_exist() {
    cat >&2 <<'MSG'
NOTE: `user does not exist [uid: 0, name: ]` from tea usually means a REVOKED OR STALE TOKEN,
      not a missing account. A `tea login` stores its OWN COPY of the token; rotating the
      credential store does NOT update it.
      CHECK: the login's cached copy (`tea login list` — read the FULL table, never `| head`),
             then re-register that login against the current token.
      DO NOT probe capability with a mutating request; a POST is the action, not a check.
MSG
}

Call site — placed immediately after the existing Warning: tea ... failed, trying Gitea API fallback... line, guarded so it is a no-op if the helper is not sourced:

declare -F explain_tea_user_does_not_exist >/dev/null && explain_tea_user_does_not_exist

Why the guard

The three call sites source detect-platform.sh on the normal path, but the declare -F guard makes each call site independent of load order and a safe no-op if the helper is ever absent. It is purely additive: no control flow changes, no gate changes, output to stderr only.

Notes

  • Purely diagnostic. It does not change what any wrapper does, only what it explains when something has already failed.
  • The last line matters and is deliberate: it discourages verifying a credential by issuing a mutating request, which is an action rather than a check.

Provenance

This helper exists on a homelab host as an undeclared local edit spanning four files (one definition, three guarded call sites). It is being contributed upstream rather than left as host divergence. Filed alongside the issue-close.sh defect found in the same audit.

No closing keywords intended; none used.

## Summary When a `tea` call fails with `user does not exist [uid: 0, name: ]`, the message is misleading: it almost always means a **revoked or stale token**, not a missing account. `tea login` stores its **own copy** of the token, so rotating the credential store does not update it. This costs real debugging time — the error points at the account, the cause is the cached credential. ## Proposal Add a small diagnostic helper in `tools/git/detect-platform.sh`, invoked from the existing tea-failure fallback paths in `issue-view.sh`, `issue-create.sh` and `pr-create.sh`: ```bash explain_tea_user_does_not_exist() { cat >&2 <<'MSG' NOTE: `user does not exist [uid: 0, name: ]` from tea usually means a REVOKED OR STALE TOKEN, not a missing account. A `tea login` stores its OWN COPY of the token; rotating the credential store does NOT update it. CHECK: the login's cached copy (`tea login list` — read the FULL table, never `| head`), then re-register that login against the current token. DO NOT probe capability with a mutating request; a POST is the action, not a check. MSG } ``` Call site — placed immediately after the existing `Warning: tea ... failed, trying Gitea API fallback...` line, guarded so it is a no-op if the helper is not sourced: ```bash declare -F explain_tea_user_does_not_exist >/dev/null && explain_tea_user_does_not_exist ``` ## Why the guard The three call sites source `detect-platform.sh` on the normal path, but the `declare -F` guard makes each call site independent of load order and a safe no-op if the helper is ever absent. It is purely additive: **no control flow changes, no gate changes, output to stderr only.** ## Notes - Purely diagnostic. It does not change what any wrapper does, only what it explains when something has already failed. - The last line matters and is deliberate: it discourages verifying a credential by issuing a mutating request, which is an action rather than a check. ## Provenance This helper exists on a homelab host as an undeclared local edit spanning four files (one definition, three guarded call sites). It is being contributed upstream rather than left as host divergence. Filed alongside the `issue-close.sh` defect found in the same audit. No closing keywords intended; none used.
Mos closed this issue 2026-08-07 05:07:41 +00:00
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
be-coder-05 be-coder-06 be-coder-07 be-coder-08 coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) merge-gate mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1)) rev-security-02 scooby (Scooby)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1082