GitHub: issue create / update / comment from list rows #75

Activity

1. Adron

   added

   parityWeb/API feature-parity workWeb/API feature-parity work

   P2DepthDepth

   area:listsArea: listsArea: lists

   area:githubArea: githubArea: github

   on Sep 15, 2026
2. Adron

   added a parent issue on Sep 15, 2026

   • Epic: GitHub integration and GitHub-backed lists #71
3. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Live probe results from the service layer (#72 / PR #142)

   ⚠️ Correction to the epic's premise: the test account IS GitHub-linked

   GET /api/user/identities shows provider github, username InterlinedListMessenger. The 200 [] from /repos and /orgs means that GitHub account owns no repos and joins no orgs — not that nothing is linked. So:

   • The genuinely-unlinked response shape is still unobserved.
   • Link state must come from /api/user/identities (GetGitHubLinkStateAsync → GitHubLinkState), never from an empty collection. Inferring "not linked" from [] would show a Connect prompt to an already-connected user.
   • ClassifyGitHubFailure / GitHubFailureReason exist as a backstop, with NotLinked flagged unverified.

   All nine endpoints, live

   Endpoint	Status	Shape
   GET /repos	200	bare array, 0 items
   GET /repos?org=github	200	559 items in one array
   GET /repos?org=dotnet	200	278
   GET /repos?org=microsoft | google | apache	200	exactly 2000 each
   GET /repos?org=Adron (a user)	404	not_found
   GET /orgs	200	bare array, 0 items — item shape never observed
   GET /issues (no repo, no default)	400	"Repository required. Set default repo in Settings or pass repo parameter (owner/repo)."
   GET /issues?repo=o/r&state=all	200	bare array, 13 items
   GET /issues?…&state=OPEN	422	validation_failed — state is case-sensitive
   GET /repos/{o}/{r}/assignees	200	bare array, capped at 30
   GET /repos/{o}/{r}/labels	200	bare array, capped at 30
   GET /repos/{o}/{r}/next-issue-number	200	{"nextNumber":14}; 1 for an issue-less repo

   POST /issues, the PATCH, and the comments endpoint were not called — they write to real GitHub repositories.

   #73 specifically: no client paging needed, but an ?org= is

   The epic said "documented as fully paginated; implement paging". Wrong in both directions. The server walks GitHub's pages itself and returns the complete set in one bare array (559 for ?org=github, well past GitHub's 100/page ceiling). There is no envelope, no Link header, and no page/per_page parameter — ?page=2&per_page=5 changed nothing. Only ?org= exists.

   But there's an apparent server cap of 2000 (three large orgs each returned exactly 2000; aws returned a natural 552), so the repo picker should show a "first 2000" hint rather than implying completeness.

   Also: /repos returns a slim server projection, not GitHub's repo object — exactly {full_name, name, private, owner_login}, uniform across all 2837 items checked.

   Conversely, issues / labels / assignees are stuck on GitHub's first 30 with no way to page further. That's a real limitation for #75.

   #76 specifically: ?link=true is load-bearing

   /api/auth/github/authorize requests only scope=user:email read:user. ?link=true is what requests repo read:org — i.e. the Issues scope. A ?scope= of your own is ignored, and an arbitrary redirect_uri is rejected.

   Separately, /api/auth/github/status carries manageOrgAccessUrl — the documented fix for missing org repos that a reconnect cannot solve (org-level third-party app approval). #76 should surface that as a distinct action, not just "reconnect".

   #74/#75: pull requests arrive as issues

   12 of 13 items from a real repo with state=all were pull requests. GitHubIssue.IsPullRequest handles it — filter or label them, or a GitHub-backed list will silently fill with PRs.