search has only a repos subcommand — no issue search, so dedup before filing means paging the whole tracker #9

• 
  @ogirardot opened this issue · Sep 7, 2026

  Evidence

  rickub search exposes only a repos subcommand. There is no issue search and
  no code search.

  Impact

  The practical consequence is that "has this already been filed?" — the question
  you must answer before opening any issue — has no cheap answer. Tonight that
  meant paging rickub issue list --json across 12 pages and grepping titles
  client-side, on a tracker with 32 open issues.

  That cost is paid by every agent and every human on every filing, and the failure
  mode when someone skips it is a duplicate issue, which is worse than the search
  being slow: it splits the evidence for one problem across two threads. It nearly
  happened today — the guest-DNS flake looked unfiled until a title grep turned up
  #367, which already had the root cause (ciguest's PID-1 reaper stealing the
  ip exit status). The measurement went on as a comment there instead of becoming
  a second, thinner issue.

  Acceptance criterion

  rickub search issues <query> [--repo owner/name] [--state open|closed|all]
  returning number, title and state, searching title and body server-side. Code
  search can follow separately — issue search is the one that gates the filing
  workflow the project's own CLAUDE.md mandates ("work you identify but don't do
  gets filed as an issue").

• 
  @ogirardot · Sep 8, 2026

  Blocked in this repo: the endpoint this asks for does not exist.

  Investigated while clearing #7, #8 and #10. rickub search issues cannot be built
  here, because there is nothing for it to call.

  What the API actually exposes

  rickub/rickub web/api.go registers exactly one search route:

  web/api.go:398: mux.HandleFunc("GET /api/v1/search/repos", h(a.apiSearchRepos))
  

  Confirmed against the live host, not just the source:

  $ rickub api GET search/issues -f q=logs
  rickub: no such endpoint (not_found)
  

  GET /repos/{owner}/{repo}/issues takes only state and the paging arguments
  (apiIssuesList, web/api_issues.go) — there is no q, so there is not even a
  per-repo filter to build on.

  What the server does have

  The web UI's global search page searches issues, via
  store.Issues.Search(ctx, query, viewerHandle, limit)
  (web/store/issues.go:180, called from handlers_dashboard.go:143). So the
  machinery is half-built, but it is not what this issue's acceptance criterion
  describes:

  #9 asks for	IssueStore.Search today
  search title and body	WHERE i.title ILIKE $2 — title only
  --repo owner/name	no repo filter
  --state open|closed|all	no state filter
  number, title, state	returns those, plus repo and author

  The UI copy says so out loud: "We search repository names and descriptions, and
  issue titles." Visibility is already handled correctly (repoVisibleClause, the
  shared authz_repo_allows predicate), so a private repo's issues are never
  surfaced to someone who cannot read them — that part would carry over for free.

  What it would take

  A server-side change in rickub/rickub, in one MR:

  1. Extend IssueStore.Search with a body match, an optional repo scope, and a
     state filter — or add a sibling method, so the dashboard's query plan is not
     changed underneath it.
  2. Register GET /api/v1/search/issues and write apiSearchIssues, paginated
     like apiSearchRepos.
  3. Then the CLI half here: SearchIssues in internal/api, and
     search issues <query> [--repo] [--state] in cmd/search.go — that part is
     perhaps 60 lines and is not the hard bit.

  Why not a client-side version

  Paging issue list --json and filtering in the CLI would move the 12-page grep
  from the human to the tool, but it is the same 12 pages on the wire, it cannot
  reach bodies at all (the list response has no body field, so it would mean one
  extra request per issue), and it would ship a command whose name promises server
  search and whose behaviour is a loop. On a tracker that outgrows one screen that
  is a worse answer than not having the command.

  Status: staying open, unstarted. #7, #8 and #10 are merged; this one is the
  only CLI issue that is not actually a CLI issue.

Sign in to comment.