Repository navigation
GitHub: InterlinedApiClient.GitHub.cs service + models #72
Description
Implement all nine /api/github/* endpoints.
Verified reachable (2026-09-15)
GET /api/github/repos → 200 []; GET /api/github/orgs → 200 []. Both answer the bearer sync-token; the empty arrays reflect no linked GitHub identity on the test account, not an auth wall.
Notes
GET /api/github/reposis documented as fully paginated — implement paging, do not assume one page.GET /api/github/orgsexists so the repo picker can group by organization.next-issue-numbersupports showing the number a new issue will get before it is created.githubDefaultRepoonGET /api/useris a per-user default worth honoring in pickers.
Acceptance criteria
- Nine service methods + models (
GitHubRepo,GitHubOrg,GitHubIssue,GitHubLabel,GitHubAssignee). - Repo listing pages through the full set.
- A missing/insufficient GitHub link is a distinguishable state, not a generic error.
- Write shapes verified live before being typed strictly (read-after-write meanwhile).
Activity
Adron commentedon Sep 16, 2026
Implemented in #142 — work continues in the PR from here.
Two surprises worth flagging. First, the premise that the test account has no GitHub link is wrong:
GET /api/user/identitiesshowsprovider: "github"asInterlinedListMessenger, and?org=githubreturns 559 repos while?repo=Adron/dashingarrivalsreturns 13 real issues — the200 []from/reposand/orgsjust means that account owns no repos and joins no orgs. The unlinked response shape is therefore still unobserved, which is why link state is read from/api/user/identitiesrather than inferred from an empty collection.Second, the pagination expectation inverts.
/api/github/reposneeds no client paging at all — the server walks GitHub's pages itself and returns the complete set in one bare array (559 and 278 items, well past GitHub's 100/page ceiling), with no envelope, noLinkheader and nopage/per_pageparams, plus a likely 2000 cap. It is issues, labels and assignees that are stuck on GitHub's first 30 with no way to page further.Also: the #76 handoff hinges on
?link=true—/api/auth/github/authorizealone requests onlyuser:email read:user, while?link=truerequestsrepo read:org— and/api/auth/github/statusturns out to carrymanageOrgAccessUrl, the documented fix for missing org repos that a reconnect cannot solve.docs: correct my own GitHub claim — the test account IS linked