limn-review 0.1.123

package/dist/github/auth.js

@@ -0,0 +1,86 @@
+import { execFile, execFileSync } from 'node:child_process';
+import { promisify } from 'node:util';
+const execFileAsync = promisify(execFile);
+const NOT_AUTHED_MESSAGE = 'gh CLI not authenticated. Run `gh auth login` first, then restart the app.\n' +
+    'For org repos behind SSO you may also need:\n' +
+    '  gh auth refresh -h github.com -s read:org';
+// ---- Token cache ----
+// `gh auth token` shells out to a child process that takes 50–300ms (longer when the OS
+// keyring prompts or the token is being refreshed), and getAccessToken() calls it for the
+// local account on EVERY request that needs a token: every PR-detail hydration, every repo
+// search, every write action. Uncached and synchronous, that both forked a process per
+// request and BLOCKED the event loop for its whole duration — so a burst of requests pinned
+// the server at 100% CPU behind a queue of `gh` processes and the dashboard stopped
+// responding.
+//
+// Caching is safe: local mode has exactly one account and one ambient gh session. The TTL is
+// short so a `gh auth refresh` / re-login is picked up without restarting, and the in-flight
+// promise collapses a concurrent burst into a single child process.
+const TOKEN_TTL_MS = 5 * 60 * 1000;
+let cached = null;
+let inFlight = null;
+/**
+ * The gh CLI token, cached with a short TTL. Prefer this everywhere on a request path — it
+ * never blocks the event loop.
+ */
+export async function getGithubTokenAsync() {
+    const now = Date.now();
+    if (cached && now - cached.at < TOKEN_TTL_MS)
+        return cached.token;
+    // A concurrent burst (e.g. the SPA opening several PRs at once) shares one `gh` invocation
+    // rather than forking one process each.
+    inFlight ??= (async () => {
+        try {
+            const { stdout } = await execFileAsync('gh', ['auth', 'token'], {
+                encoding: 'utf-8',
+            });
+            const token = stdout.trim();
+            if (!token)
+                throw new Error('empty token');
+            cached = { token, at: Date.now() };
+            return token;
+        }
+        catch {
+            throw new Error(NOT_AUTHED_MESSAGE);
+        }
+        finally {
+            inFlight = null;
+        }
+    })();
+    return inFlight;
+}
+/**
+ * Synchronous variant. Kept for the STARTUP path (`cli.ts`'s pre-flight check and
+ * `ensureLocalAccount`) and for the few local-only helpers that are not on a request path,
+ * where blocking once is fine and threading async through would be churn for no gain.
+ * Shares the cache with the async form, so a request path that has already warmed it never
+ * forks a process here either.
+ *
+ * Do NOT call this from a request handler — use `getGithubTokenAsync`.
+ */
+export function getGithubToken() {
+    const now = Date.now();
+    if (cached && now - cached.at < TOKEN_TTL_MS)
+        return cached.token;
+    try {
+        const token = execFileSync('gh', ['auth', 'token'], {
+            encoding: 'utf-8',
+        }).trim();
+        if (!token)
+            throw new Error('empty token');
+        cached = { token, at: Date.now() };
+        return token;
+    }
+    catch {
+        throw new Error(NOT_AUTHED_MESSAGE);
+    }
+}
+/**
+ * Drop the cached token. Call after GitHub rejects it with a 401 so the next request
+ * re-reads it from `gh` (which may have refreshed it) instead of retrying a dead token for
+ * up to the TTL.
+ */
+export function invalidateGithubToken() {
+    cached = null;
+}
+//# sourceMappingURL=auth.js.map

package/dist/github/branch-queries.js

@@ -0,0 +1,229 @@
+// Default-branch ("is trunk green?") GraphQL.
+//
+// Deliberately its OWN file rather than an addition to `github/queries.ts`: that module is the
+// PR-shaped activity walk (one fat query, lean-gated field interpolation, shared PR node
+// fields), and this query shares none of it. Keeping them apart means a change to the trunk
+// snapshot can never perturb the backfill's page shape.
+//
+// Cost: ~4 rate-limit points per repo per sync at the 100-commit window — still the whole point
+// of asking for the commit history AND its per-commit rollup in a single round trip.
+//
+// Nullability, verified field-by-field against GitHub's published SDL (every one of these is a
+// real runtime case, not defensive noise):
+//   • `Repository.defaultBranchRef` is nullable — an empty repo has no default branch.
+//   • `Ref.target` is nullable AND an interface (`GitObject`), so the `... on Commit` inline
+//     fragment is MANDATORY; a branch pointing at a tag object yields `{}` here.
+//   • `Commit.statusCheckRollup` is nullable — a commit no CI ever ran on. It IS defined on
+//     Commit directly (not only reachable via a PR).
+//   • `Commit.author` is a nullable `GitActor`, and its `user` is null whenever the commit's
+//     email maps to no GitHub account (the classic "committed from a laptop with a personal
+//     email" case) — so `author.name` is the only identity such a commit carries.
+//   • `Commit.associatedPullRequests` is a NON-NULL connection in the SDL, and so are its
+//     nodes' `number` / `merged` / `baseRefName` / `repository`. They are nonetheless typed
+//     optional below for one specific reason: `graphqlTolerant` (github/client.ts) hands back
+//     `err.data` on a PARTIAL GraphQL error, where forbidden fields arrive NULLED regardless of
+//     their declared nullability. Everything a partial response can null must be optional here,
+//     or the mapper would trust a field TypeScript merely believes is present. The connection's
+//     `nodes` elements are `[PullRequest]` — genuinely nullable even on a clean response.
+//
+// COST, and why this file is structured in two phases:
+// GitHub scores a GraphQL call from the nodes its connection arguments request (multiply nested
+// first/last down each path, sum, then ceil(total/100), min 1). Phase 1 below asks for
+// history(first: 100) × associatedPullRequests(first: 3) = 100 + 300 = 400 nodes ⇒ FOUR points,
+// which is what the "~4 points per repo per sync" promise above means (the widening from 20 to
+// 100 — 80 nodes, one point — is an accepted cost; it feeds the branch-trends charts). Nesting
+// `statusCheckRollup.contexts(first: 100)` under that history would be 100 + 100×100 = 10100
+// nodes ⇒ ~102 points on EVERY walk of EVERY repo, green or red, on a call adaptive polling
+// re-fires every 120s for a hot repo. So the failing-check DETAIL is a SECOND query
+// (`buildCommitChecksQuery`) issued only for the commits whose rollup phase 1 already reported
+// as failure/error/pending. A green trunk therefore costs exactly the phase-1 walk.
+// One trunk-commit node, shared VERBATIM between the live snapshot query and the history
+// backfill below — the two walks must store identical rows, so the selection is written once.
+//
+// On `associatedPullRequests`: first:3 rather than 1 because the connection has NO documented
+// ordering, so first:1 would be a non-deterministic pick that could FLIP between syncs; and
+// rather than 10 because 3 keeps the node budget described above at N + 3N (4 points at the
+// 100-commit window, vs 11 for first:10). merged + baseRefName are the ranking inputs (see
+// pickAssociatedPrNumber in sync/branch-status.ts); repository.nameWithOwner exists because
+// this connection spans the repo NETWORK, so a fork's own PR can appear and its number would
+// resolve against the WRONG repo at read time.
+const BRANCH_COMMIT_FIELDS = /* GraphQL */ `
+                oid
+                messageHeadline
+                committedDate
+                statusCheckRollup {
+                  state
+                }
+                author {
+                  name
+                  avatarUrl
+                  user {
+                    login
+                  }
+                }
+                associatedPullRequests(first: 3) {
+                  nodes {
+                    number
+                    merged
+                    baseRefName
+                    repository {
+                      nameWithOwner
+                    }
+                  }
+                }
+`;
+// `StatusState` (SUCCESS | FAILURE | PENDING | ERROR | EXPECTED) is exactly the enum the
+// existing PR rollup mapper already switches on, so the persist layer reuses that mapping
+// rather than inventing a second vocabulary.
+export const DEFAULT_BRANCH_QUERY = /* GraphQL */ `
+  query DefaultBranchStatus($owner: String!, $name: String!, $first: Int!) {
+    rateLimit {
+      cost
+      remaining
+    }
+    repository(owner: $owner, name: $name) {
+      defaultBranchRef {
+        name
+        target {
+          ... on Commit {
+            oid
+            statusCheckRollup {
+              state
+            }
+            history(first: $first) {
+              nodes {
+${BRANCH_COMMIT_FIELDS}
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+`;
+// The one-time HISTORY BACKFILL twin of the snapshot query: the same commit nodes, but
+// paginated (`after`) and server-bounded to the trend window (`since` — GitTimestamp, filters
+// on committer date). Same 4-points-per-page cost as the snapshot; the caller caps pages.
+// `since` means an exhausted walk ends at the window edge with hasNextPage:false rather than
+// crawling into ancient history.
+export const DEFAULT_BRANCH_HISTORY_QUERY = /* GraphQL */ `
+  query DefaultBranchHistory(
+    $owner: String!
+    $name: String!
+    $first: Int!
+    $since: GitTimestamp!
+    $after: String
+  ) {
+    rateLimit {
+      cost
+      remaining
+    }
+    repository(owner: $owner, name: $name) {
+      defaultBranchRef {
+        name
+        target {
+          ... on Commit {
+            history(first: $first, since: $since, after: $after) {
+              pageInfo {
+                hasNextPage
+                endCursor
+              }
+              nodes {
+${BRANCH_COMMIT_FIELDS}
+              }
+            }
+          }
+        }
+      }
+    }
+  }
+`;
+// The failure-detail selection. `contexts` is a UNION (CheckRun | StatusContext), so both inline
+// fragments are MANDATORY and `__typename` is what the mapper switches on — byte-identical to
+// the PR walk's headCommit selection plus the workflow name.
+//
+// `first: 100` deliberately matches the PR walk. Do NOT lower it: `contexts` has no documented
+// ordering that puts failures first, so a smaller page can return 100 green contexts on a commit
+// whose rollup says FAILURE — i.e. an empty failures array on a red commit, a caret with nothing
+// behind it. checkSuite/workflowRun/workflow are plain OBJECTS, not connections, so they add zero
+// nodes and therefore zero rate-limit cost.
+const COMMIT_CHECKS_SELECTION = /* GraphQL */ `
+  oid
+  statusCheckRollup {
+    state
+    contexts(first: 100) {
+      nodes {
+        __typename
+        ... on CheckRun {
+          name
+          status
+          conclusion
+          detailsUrl
+          checkSuite {
+            workflowRun {
+              workflow {
+                name
+              }
+            }
+          }
+        }
+        ... on StatusContext {
+          context
+          state
+          targetUrl
+        }
+      }
+    }
+  }
+`;
+// How many commits one phase-2 call will ask about. Most commits anyone ever expands are the
+// newest few, and capping the alias count caps the worst case (a 100-commit all-red window) at
+// ~10 points instead of ~100 — the pathological case is precisely the one where you don't need
+// 100 carets to know trunk is broken.
+export const COMMIT_CHECKS_ALIAS_CAP = 10;
+/**
+ * One query with `count` aliased `repository.object(oid:)` lookups, each selecting that commit's
+ * check contexts.
+ *
+ * The shas ride as GraphQL VARIABLES (`$s0`…`$sN` of type `GitObjectID!`), never interpolated
+ * into the query text: the only generated part is the alias names, and those are INDEX-derived
+ * (`c0`, `c1`, …), never data-derived. Cost is `count` nodes for the objects plus 100 contexts
+ * each ⇒ ceil((count × 101)/100) ≈ `count` points, which is why the caller only ever passes the
+ * commits phase 1 already reported as non-green.
+ */
+export function buildCommitChecksQuery(count) {
+    const vars = Array.from({ length: count }, (_, i) => `$s${i}: GitObjectID!`).join(', ');
+    const aliases = Array.from({ length: count }, (_, i) => `      c${i}: object(oid: $s${i}) { ... on Commit { ${COMMIT_CHECKS_SELECTION} } }`).join('\n');
+    return `query CommitChecks($owner: String!, $name: String!, ${vars}) {
+    rateLimit {
+      cost
+      remaining
+    }
+    repository(owner: $owner, name: $name) {
+${aliases}
+    }
+  }`;
+}
+// ---- Per-commit rollup STATE, in bulk (the PR CI-history backfill) ------------------------
+//
+// The state-only sibling of `buildCommitChecksQuery`: one aliased `object(oid:)` per sha,
+// selecting nothing but the rollup state. No connection arguments anywhere in the selection, so
+// the whole call costs ~1 rate-limit point regardless of alias count — which is what makes a
+// 100-per-call cap affordable where the contexts query must stop at 10.
+export const COMMIT_STATES_ALIAS_CAP = 100;
+/** Same alias/variable discipline as `buildCommitChecksQuery`: index-derived alias names, shas as
+ * `GitObjectID!` variables, never interpolated into the query text. */
+export function buildCommitStatesQuery(count) {
+    const vars = Array.from({ length: count }, (_, i) => `$s${i}: GitObjectID!`).join(', ');
+    const aliases = Array.from({ length: count }, (_, i) => `      c${i}: object(oid: $s${i}) { ... on Commit { oid statusCheckRollup { state } } }`).join('\n');
+    return `query CommitStates($owner: String!, $name: String!, ${vars}) {
+    rateLimit {
+      cost
+      remaining
+    }
+    repository(owner: $owner, name: $name) {
+${aliases}
+    }
+  }`;
+}
+//# sourceMappingURL=branch-queries.js.map