Flux source URL, flux-git rotator verify repo, review-bot REPOS, pipeline API,
clone and push URLs, the heating-can source label and the review-bot and
kuma-sync Go module paths. Merge right after the transfer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The bot posted approvals with event "APPROVE". Gitea knows APPROVED,
REQUEST_CHANGES and COMMENT and stores any other value as a pending review
that only its author sees (routers/api/v1/repo/pull_review.go,
preparePullReviewType, default branch). Every approval since cdba8b62 is such
a pending draft: homelab #1270, #1278, #1287, #1318, homeassistant #385.
The bot also counted its own pending review as "reviewed at this head", so
those PRs were never reviewed again. A pending review no longer counts; the
sweep reviews them again, and Gitea submits the existing pending review with
the new event.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mistral cut every POST /conversations off with HTTP 502 exactly ten minutes
after it started (about 30 times in the last 7 days), and every retry restarted
the whole review, so a review needing more than ten minutes could never finish.
- Mistral: the conversation now streams (stream=true, SSE). A stream that
breaks off after the conversation started is looked up in the stored history
(store=true, GET /conversations/{id}/history) before it is asked again. A
broken stream is retryable like 429/502/503/504; a
conversation.response.error event is not. One agent per model, named
<AGENT_NAME>-<model>.
- Anthropic: new backend on the Messages API (Go SDK, streaming, adaptive
thinking, effort high). Anthropic connects to the Gitea MCP server
(gitea-mcp.renner.uno/mcp) with a read-only token; the toolset is in
allowlist mode with only the read tools enabled. Paused turns are resumed,
refusals use the server-side fallback on Opus/Sonnet 5.5.
- Models: MODELS lists backend:model = description, the first is the default.
A backend whose keys are missing is switched off with a warning instead of
stopping the bot.
- Selector: SELECTOR=typesafe asks TypeSafe (Jev, Choice) which model reviews
each PR, from the title, description, size and changed files. A failure or
an unusable choice falls back to the default model.
- Secrets: the Anthropic and TypeSafe keys reuse the wiki keys
(apps/ai/wiki-anthropic, apps/ai/wiki-typesafe), like the Mistral key does.
The MCP token is a second review-bot PAT scoped read:repository,read:issue,
read:user, minted by a new rotate-mint-mcp step into
infrastructure/review-bot#mcp_token (seeded with a placeholder). Each
optional key has its own ExternalSecret and optional env ref.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every phase of a pull request's review is now visible in two places:
- a commit status "review-bot" on the reviewed head: pending while
queued, running or waiting to retry; success once reviewed (with the
verdict) or skipped; error with the reason when the review failed;
warning when new commits superseded the reviewed head. The statuses
are posted one at a time in order, so a later phase never lands before
an earlier one, and never block the queue.
- GET /status and GET /status/{owner}/{repo}/{n}: the in-memory state
of every PR seen since start, with the queue position while queued.
Finished entries are dropped after a day.
Until now a failed review posted nothing, so a PR whose review failed
looked the same as one still waiting.
Also gofmt report_test.go, which the CI gofmt check flags on master.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The bot has no cluster access, so any PR citing live-cluster evidence
gets a ⚪ Unverified section and could never be approved (e.g. #1281).
Approval now requires only no 🔴/🟡 section, matching the review banner
("approves only when it found nothing red or yellow"); the prompt's
verdict rule is aligned.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The agent can read its earlier review but nothing told it to. A re-review now opens with the
state of every earlier point, judges the new commits in full, and leaves unchanged code as it
was judged: no new suggestions, unverified points or nits about it, and no requests for more
tests or hardening of code that did not change.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A 502 after ten minutes ended a review of homeassistant#382 with nothing posted. 502, 503 and
504 are retried like the 429, with the same waits and the same retry budget. The metrics are
now retries_total and retry_giveups_total.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The guessed wait (RATE_LIMIT_WAIT x retry) was uncapped while Retry-After was capped, so a large
RATE_LIMIT_WAIT could outlast the review budget. Both now share one constant.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A Blocking section that said 'none' but held a sentence turned the review into
REQUEST_CHANGES. The agent now ends its report with 'Verdict: request-changes|comment|approve';
no verdict means a plain comment, and an approval is downgraded when the report still holds
red, yellow or unverified sections.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Drops the text matching on tool results. The observed limit is HTTP 429 on starting a
conversation, which is handled by status; guessing at tool output text cannot be made
correct and dropped reviews when it was wrong.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A review whose head moved during the conversation is not posted; the PR is reviewed
again at the new head. A request that arrives while a PR is being reviewed is no
longer lost: the PR is reviewed once more when the running review ends. Tool errors
count as rate limits only with a limit phrase (429 as a status, too many requests,
rate limit reached/exceeded), so file names like rate_limit.go do not match. The whole
review is capped at one conversation timeout plus the longest waits.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A tool result that merely contains the words 'rate limit' (a file about rate limits)
no longer marks the answer incomplete. Only short error messages naming a limit
(rate limit/rate_limit/ratelimit, too many requests, 429) count. Each conversation
gets the full review timeout, the waits between retries do not eat into it, and a
give-up is counted in rate_limit_giveups_total. Tests pin the first retry delay,
the Retry-After cap and the false positive.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Replaces the hand-rolled retry loop with a failsafe-go retry policy: handles 429 and
rate-limited tool results only, delay from Retry-After (capped at 5m) else linear
backoff, context-aware.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Mistral documents requests per second (concurrent requests), tokens per minute and tokens per month, and X-RateLimit-Remaining, but no Retry-After and nothing about connector tool calls. When a 429 carries Retry-After it is used instead of the guessed wait (capped at five minutes); the Retry-After and rate limit headers of every 429 are logged.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A conversation that got HTTP 429, or whose tool calls failed on the rate limit, is asked again after a growing wait (RATE_LIMIT_RETRIES, RATE_LIMIT_WAIT) instead of failing or posting a review built on half the files. The default is one worker, and the review timeout covers the waits.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Gitea's pull_request webhook (HMAC-checked) queues the review at once; a periodic sweep over the configured repositories catches lost deliveries. The service keeps the listed Mistral agent in sync with the embedded prompt, asks it for a review, refuses answers that called non-read-only tools, cleans the report, derives the review event and posts as the review bot. State is the pr-review:sha marker in the bot's own review. /healthz, /readyz and /metrics. Standard library only, tests against fake Gitea and Mistral servers, built as a scratch image by build-ci-images.yml.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
