# Turn Labeled GitHub Issues Into Pull Requests for a FastAPI App

Send a labeled FastAPI issue to Rush for a users-or-items route fix, database-backed pytest coverage and a pull request that links the issue.

[Run this on Rush](https://cloud.getrush.ai/run/github-issue-to-pr/fastapi/), in a Project that has your repository.

## What the agent does

The agent starts from the issue's expected behavior and reads the FastAPI application's backend before editing it. In fastapi/full-stack-fastapi-template, backend/pyproject.toml:5 requires Python >=3.14,<4.0, line 16 declares SQLModel and line 13 declares Alembic. The backend test wrapper is explicit: backend/scripts/test.sh:6 runs FASTAPI_ENV=development coverage run -m pytest tests/. The agent works from backend for Python checks and avoids treating the React frontend's commands as backend verification.

It traces the reported users or items endpoint through dependencies, models and persistence. backend/app/api/routes/items.py:56–57 refuses an item read when the current user is neither a superuser nor its owner, with detail="Not enough permissions". Lines 29–40 also restrict ordinary users' list queries by Item.owner_id. These branches matter when an issue looks like a missing item but is really an access-control expectation. The agent builds its reproduction around the supplied user role rather than disabling permissions to satisfy a happy-path assertion.

The test uses the real application client and a disposable database. backend/tests/conftest.py:15–24 defines an autouse db fixture that initializes the database and deletes Item and User rows during teardown. That cleanup makes an isolated test database mandatory. backend/tests/api/routes/test_items.py:55–65 already exercises a forbidden item read and checks the response detail. A new regression extends the relevant behavior without replacing SessionDep, CurrentUser or the database with success stubs.

For user-profile bugs, the agent checks the separate /me path before altering administrative operations. backend/app/api/routes/users.py:81–99 implements @router.patch("/me", response_model=UserPublic) and rejects a conflicting email with status_code=409. The fix stays within the issue's route, schema or persistence boundary. The agent runs focused pytest coverage, the backend test wrapper and reports actual outputs. It opens a pull request with the cause and Closes #<issue>, while leaving deployment and merging to review.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Fix the labeled GitHub issue appended below in this FastAPI application. Require its URL, repository issue number, reported request, caller role, observed response and acceptance criteria. Read backend configuration and the users and items routes before changing anything. Reproduce the reported bug with pytest against the real FastAPI application and a disposable database; never use a production database because test fixtures delete rows. Preserve owner and superuser permissions. Make the narrow fix, run focused pytest from backend and the repository's backend test wrapper, and report the exact commands and outcomes. Open a pull request explaining the cause and including Closes #<issue> with the supplied issue number. Do not merge, deploy, or change unrelated frontend code.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

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

The PR contains the failing behavior's correction and pytest coverage that demonstrates the intended users or items contract. Its description separates the targeted reproduction from the broader backend suite. If the issue requires a model change, the reviewer sees the model and migration consequences together rather than an unexplained schema adjustment. The session result points to the PR and summarizes the actual validation, including any database or interpreter setup error.

Before merging, the maintainer verifies both allowed and forbidden requests. For items, that means preserving isolation between ordinary users as well as the superuser path. For profile changes, it means checking duplicate-email handling and which fields an ordinary caller can update. The reviewer inspects backend/tests/conftest.py's cleanup assumptions and confirms that the test evidence comes from a disposable environment. This is the intended deliverable, not a claim that the public template has a particular unfixed bug.

## Run it on every triaged FastAPI issue label

A caller-owned GitHub webhook handler accepts issues.labeled only for your approved repository and label. It retrieves the issue and relevant comments, appends that context to input and starts a session through POST /o/{org}/sessions. Include the backend path and environment requirements when your application differs from the template. Deduplicate GitHub deliveries and avoid starting another branch for an issue already being implemented.

Keep label assignment behind maintainer triage, especially for reports involving user permissions. The handler can read the session result or receive the API key's completion webhook to recover the PR link. A missing reproduction, inaccessible database or failed test is a result to surface back to the maintainer, never a reason to manufacture a completed fix.

## Why run it on Rush?

FastAPI route work often needs a clean database and several caller identities. Rush gives the task its own sandbox, where the agent can prepare disposable state without touching the engineer's current SQLModel data. That separation matters for this template because the pytest fixture deletes rows after the session. A local reproduction copied into the wrong environment could otherwise damage useful development state.

Separate issues can be analyzed in separate runs within the key's concurrency limit. The transcript keeps the pytest command, its output and the file operations, so a reviewer can distinguish an ownership regression from a failed database connection. The returned patch has an issue, a reproduction and an audit trail attached to it. The maintainer can judge the evidence without reconstructing an agent's terminal session by hand.

## Frequently asked questions

### Does a passing status-code assertion prove the authorization fix?

The test should also check who owns the affected record and what data is returned or changed. An allowed owner request and a refused cross-user request establish different parts of the contract. Keep both when the issue affects permissions.

### Can the agent run pytest against my development database?

Use a disposable database dedicated to this task. The template's autouse fixture deletes items and users during teardown. The request explicitly excludes production data and should not reuse valuable local data either.

### Will it update the frontend for every backend issue?

No. The request targets users and items behavior in the FastAPI backend. A frontend change belongs in the patch only when the issue's acceptance criteria require it and the reviewer can see the connection.

### Where does the GitHub issue text enter the run?

Your webhook handler appends the issue and comments to the input string. The repository resource gives the agent its checkout. The example does not pretend that an issue URL alone is a supported repository resource.