# Review Pull Requests on a Rocket Server

Yes. An agent checks out the Rocket pull request, runs clippy and the tests with the repository's feature matrix, and posts one review citing file and line.

[Run this on Rush](https://cloud.getrush.ai/run/review-pull-requests/rocket/), in a Project that has your repository.

## What the agent does

The agent checks out the pull request's branch in its own sandbox and reads how the repository tests itself before it reads the diff. In dani-garcia/vaultwarden, `.github/workflows/build.yml` runs on every push that touches `src/**`, `migrations/**`, `Cargo.*`, `build.rs`, `rust-toolchain.toml`, `rustfmt.toml`, `diesel.toml` or `macros/**`, with a two-row matrix: the `rust-toolchain` channel, 1.99.0 from `rust-toolchain.toml`, and `msrv`, 1.97.1 from `rust-version` in `Cargo.toml`. It installs `libmariadb-dev-compat`, `libpq-dev`, `libssl-dev` and `pkg-config`, sets `RUSTFLAGS=-Dwarnings`, and runs `cargo test --profile ci` six times over feature sets: all five features, without `s3`, without `enable_mimalloc`, then `sqlite`, `mysql` and `postgresql` alone. Clippy runs once with `sqlite,mysql,postgresql,enable_mimalloc,s3`, and `cargo fmt --all -- --check` on the toolchain row only. The agent runs the toolchain row: `cargo test --profile ci --features sqlite` first for speed, then clippy with all features and the fmt check, and quotes each result in the review.

Then it reads the diff with the files the change depends on. A handler in `src/api/core/` is an `async fn` with request guards from `src/auth.rs` and a `DbConn`; the agent checks which guard the new route takes, since `Headers` admits any logged-in user while `OrgHeaders`, `AdminHeaders`, `ManagerHeaders` and `OwnerHeaders` check membership and role, and a route that reads organization data behind `Headers` alone is a finding. Queries go through `conn.run(move |conn| ...)` or `db_run!`, which compiles a body per backend, so a Diesel expression that uses a SQLite-only function or a type the Postgres schema does not have is caught by the three-backend clippy run and quoted with the compiler message. A new table or column must appear in all four `migrations/` directories (`sqlite`, `mysql`, `postgresql`, `cockroachdb`) and in `src/db/schema.rs`, and the review lists any backend the change forgot.

The error contract gets its own pass. `src/error.rs` turns every `err!` into a 400 with an `ApiErrorResponse` body and logs the message at error level, so the review flags an `unwrap()` or `expect()` on data that comes from the client or the database, a `?` on a type with no `From` impl, and a message that leaks an internal path. `[workspace.lints.rust]` forbids `unsafe_code` and denies `warnings` and the edition compatibility groups; `[workspace.lints.clippy]` warns on `pedantic`, `style`, `perf` and `suspicious`, and CI's `-Dwarnings` turns those into failures, so a `needless_pass_by_value` in a new helper is a blocking finding with the clippy line attached. `rustfmt.toml` sets `max_width = 120` and `use_small_heuristics = "Off"`, which the fmt check enforces.

The review is one GitHub review with blocking findings separated from suggestions, each citing file and line, and the three command results at the top. The agent pushes no commits and opens no second pull request. A change under `playwright/` or `docker/` is noted as outside the Rust checks, since the Playwright suite needs Docker Compose and the Dockerfile has its own `hadolint.yml` workflow.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Review the open pull request on this Rocket server. Check it out and read .github/workflows/build.yml, rust-toolchain.toml and Cargo.toml first; in a server shaped like dani-garcia/vaultwarden, build with the pinned toolchain and RUSTFLAGS=-Dwarnings, run cargo test --profile ci --features sqlite, cargo clippy --profile ci --features sqlite,mysql,postgresql,enable_mimalloc,s3 and cargo fmt --all -- --check, and quote each result. Read the diff with the files it depends on: the request guards in src/auth.rs that each changed route takes, the Diesel queries run through conn.run or db_run! and whether they compile for every backend, the migrations/ directories a schema change must all update, and every unwrap, expect or err! on data from the client or the database. Post one GitHub review that cites file and line for every finding, separates blocking issues from suggestions, and includes the command results. Do not push commits.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app/pull/1"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a review on the pull request and the full command log on the session. The review opens with the results of `cargo test --profile ci --features sqlite`, the five-feature clippy run and the fmt check, then lists blocking findings and suggestions, each with a file and line: a guard that admits too much, a query that only compiles for SQLite, a missing MySQL migration, an `unwrap` on a client value. A compile or clippy failure is quoted as the result rather than worked around.

Before acting on it, a maintainer checks the guard findings first, since they decide who can reach data, then the backend findings, and treats the style items as optional. The session's `result` holds the review text, and the transcript shows every command with its output, so a finding can be traced to the line of compiler or clippy output that produced it.

## Run it on every pull request opened

Create an automation in the Project with this prompt and a `github` trigger on `pull_request.opened` and `pull_request.synchronize`, with `read_only` on so its runs can comment but never push. The trigger adds the pull request event after the prompt, and each push to the branch starts a fresh run against the new head. Set `max_runs_per_hour` to match how often the team pushes, since a server this size compiles for several minutes per run.

To drive it from your own server instead, receive the GitHub webhook, put the pull request URL in `resources` so the clone is the head commit, and send this body with the delivery id as `Idempotency-Key`. A webhook URL on the key then receives `run.completed` with `session_url` when the review is posted; the first build of a Vaultwarden-sized crate is long, and a key allows at most `max_concurrent` runs in progress, so start the next review when one finishes.

## Why run it on Rush?

A Rocket server that compiles against three databases and denies every warning cannot be reviewed from the diff alone: the question is whether the query compiles for Postgres, whether the guard is the right one, and whether clippy's `pedantic` group passes under `-Dwarnings`. On Rush the agent runs those checks in its own sandbox with the pinned toolchain and the system libraries CI installs, and the review quotes what the compiler said instead of guessing.

Every pull request gets the same depth, with the full command record kept on the session, and several open pull requests are several sandboxes at once. The reviewer who merges reads findings with evidence rather than waiting for the CI matrix to say what the agent already found.

## Frequently asked questions

### cargo test passed with the sqlite feature. Did the other backends run?

The tests ran on SQLite, and clippy compiled the crate with `sqlite,mysql,postgresql,enable_mimalloc,s3`, which is how CI catches a query that only works on one backend. The review says exactly that, and a maintainer can ask for a follow-up turn that runs `cargo test --profile ci --features postgresql` with a Postgres started in the sandbox.

### Will it flag style under the pedantic group?

Yes, as blocking when CI would fail on it, because `-Dwarnings` turns the `warn` level in `[workspace.lints.clippy]` into an error, and as a suggestion otherwise. Each item carries the clippy line so you can decide.

### Does it check the migrations?

It lists the files added under each of `migrations/sqlite`, `migrations/mysql`, `migrations/postgresql` and `migrations/cockroachdb` and the change to `src/db/schema.rs`, and names any backend the pull request skipped. It does not run the migrations against MySQL or Postgres unless asked.

### Can it review a change to the Playwright tests or the Dockerfile?

It reads them and comments on what it can see, but the Rust commands do not cover them; `playwright/` needs Docker Compose with three databases and the Dockerfile is checked by `hadolint.yml`. The review labels those findings as read-only.