Greptile review (PR #438) flagged two issues:
1. search_github and enrich_with_comments both call _resolve_token,
so when GITHUB_TOKEN is absent from config and env the gh-CLI
subprocess (with its 5s timeout) fires twice per query.
2. The no-token early-return envelope `{"items": [], "error": "no token"}`
was missing the `context` key that every other failure path includes,
making the envelope shape inconsistent between the no-token and
fetch-failure cases.
Fix 1: add public github.resolve_token(token) wrapping the existing
_resolve_token. Pipeline calls it once before search and enrich, so
both downstream calls receive an already-resolved (or already-None)
token and skip the fallback chain.
Fix 2: thread core/from_date/to_date/count through the no-token
envelope's `context` key, matching the fetch-failure envelope shape.
parse_github_response was already tolerant of the missing key, but
diagnostics callers that read response["context"]["..."] now get a
consistent dict in both error paths.
Reviewer's suggested code patch for issue 1 was a no-op (it kept the
same _resolve_token(token) call inside enrich_with_comments); the
underlying intent — resolve at the boundary — is what this commit
implements.
Ilia Alshanetsky
c5c0239dc9