Add openIssuesCount to RepoResponse#8
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 22 minutes and 15 seconds.Comment |
Summary
Surface a repo's open-issues count on the details screen + everywhere else
RepoResponseis returned. No new endpoint, no pagination -- the count rides on the existing repo response shape.GitHub's
open_issues_countincludes both open issues AND open PRs (GitHub treats PRs as a kind of issue). Same number the GitHub website shows on the Issues tab. Documented in the field comment + the client integration guide so the client UI labels it correctly ("Issues" not "Bugs").Changes
Per
CLAUDE.md's RepoResponse-fan-out checklist:db/migration/V14__open_issues_count.sql-- addsopen_issues INT NOT NULL DEFAULT 0. Idempotent (ADD COLUMN IF NOT EXISTS).db/DatabaseFactory.kt-- registers V14 in the migrations list.db/Tables.kt-- Exposed column onRepos.model/RepoResponse.kt-- newopenIssuesCount: Int = 0field.db/RepoRepository.kt-- maps the column on every category/topic/repo DB read.db/MeilisearchClient.kt-- addsopen_issuestoMeiliRepoHit.ingest/GitHubSearchClient.kt-- new field onGitHubRepo(deserialized from GitHub'sopen_issues_count), upsert writes it to Postgres, sync writes it to Meili,RepoWithRelease.toRepoResponsecarries it.routes/RepoRoutes.kt--toMetadataOnlyResponse()(lazy-fetch path) carries it.routes/SearchRoutes.kt--MeiliRepoHit.toRepoResponse()carries it.Existing curated rows have
open_issues = 0until any of the four write paths fires:POST /v1/repo/{o}/{n}/refresh(immediate when user taps refresh)RepoRefreshWorkerhourly cycle (passthrough rows by oldestindexed_at)db_writer.py+meili_sync.pyare updated)The Python fetcher repo update is not in this PR -- it lives in a separate repo. Backend is forward-compatible: rows update gracefully as they're touched.
Client integration
docs/client/open-issues-count.md-- standalone guide for the client coding agent. Covers the field shape, display recommendations, backwards compatibility (Int = 0default +ignoreUnknownKeys), and what NOT to wire (no separate list endpoint, no pagination).Test plan
./gradlew test-- all suites green./v1/repo/sindresorhus/refined-github-- expectopenIssuesCountfield present in JSON.POST .../refreshthen re-fetch -- expect non-zero.open_issues_countfrom the GitHub response into Postgres + propagate via meili_sync.