What the agent does
The agent starts from the Linear issue and the repository in its own sandbox, and reads how HTTP logging is wired today. In a codebase like launchbadge/realworld-axum-sqlx (edition 2021, axum 0.3.4, tower-http 0.2 with the trace feature already in Cargo.toml), src/http/mod.rs already applies TraceLayer::new_for_http() in a ServiceBuilder and comments RUST_LOG=tower_http=debug. src/main.rs still calls env_logger::init() after dotenv, and comments in src/http/error.rs assume TraceLayer links errors to the request. There are no automated tests in the tree.
The gap against the issue is usually request IDs on spans and JSON logs through tracing-subscriber instead of (or in addition to) env_logger's plain lines. The agent plans: keep or upgrade tower-http's TraceLayer, attach a request id extension and make it a span field, replace env_logger::init() with a tracing-subscriber registry that emits JSON and respects RUST_LOG, and document the env var in the README or .env.example if one exists.
It implements that in src/main.rs and src/http/mod.rs, adjusting for the crate's older axum 0.3 AddExtensionLayer style rather than rewriting the whole router. It adds tests that build the router (or a minimal stack) with TraceLayer, fire a request and assert a request id header or span field is present, starting Postgres in the sandbox when the test path needs SQLx migrations the same way main runs sqlx::migrate!().
Last, it runs cargo test with Postgres available, fixes compile errors from subscriber feature flags, and opens a pull request that links the Linear issue and records the RUST_LOG values that produce JSON request lines.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Linear issue labeled agent says: \"Add Request Tracing to an Axum API. Add tower-http's TraceLayer with a request ID on every span and JSON logs through tracing-subscriber, configurable with RUST_LOG.\" Do the work in this repository, add tests for it, run cargo test with Postgres started in the sandbox, and open a pull request that links back to the issue.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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.
- 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.
- 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 pull request on its own branch. The description notes that TraceLayer was already present but logging still went through env_logger, then shows the subscriber swap, request id on spans and any Cargo feature adds. The Linear issue is linked from the PR body.
The transcript keeps Postgres startup, migrations if run, and every cargo test invocation with its output. Missing proof stays visible in the session rather than as a silent green merge.
Before merging, a reviewer checks that RUST_LOG still filters noise, that request ids do not leak secrets, that error paths in http/error.rs still correlate with spans, and that tests fail if TraceLayer is removed from the stack.
Run it on every Linear issue labelled agent
In the console, an automation with a linear trigger on linear.issue.labeled and the label agent starts one run per labelled issue, with the issue as its context, in the Project's repository. Changes made by an app integration never fire it, so the agent's own updates do not start new runs.
From your own server, the same run is one POST /o/{org}/sessions per issue: put the repository in resources, and add the issue's https://linear.app/<workspace>/issue/<ID> URL there too to have Rush read it through your Linear connection into the prompt. A webhook on the API key posts run.completed or run.failed when the turn finishes, with the session_url to read the result.
The use case this job follows, with its automation and trigger: Turn a Linear label into a PR.
Why run it on Rush?
This crate expects Postgres for a real boot (PgPoolOptions and embedded migrations in main). A Rush sandbox starts Postgres, runs cargo test and keeps the log, so subscriber feature mismatches and migration failures show up without touching a shared developer database.
A Linear label becomes a PR with the tracing change isolated on its own branch. Several labelled Rust API issues can run at once, each with its own sandbox and branch, up to the key's max_concurrent limit, and the transcript is the proof that RUST_LOG was exercised.
Frequently asked questions
The repo already has TraceLayer. Will it add a second one?
No. The agent reads src/http/mod.rs first. If TraceLayer is already on the ServiceBuilder, it extends that layer with request ids and fixes the subscriber side instead of stacking another TraceLayer.
Why start Postgres for tracing tests?
Because this RealWorld app's serve path and migrations assume a live DATABASE_URL. Tests that build the full router need the same dependency the binary does; the sandbox starts Postgres so those tests are real.
Does it keep env_logger?
Not as the primary request logger. The issue asks for tracing-subscriber JSON controlled by RUST_LOG; the agent removes or demotes env_logger::init() and documents the new variable.
Which tower-http version does it target?
Whatever Cargo.toml already pins (0.2.0 with features = ["trace"] in the Launchbadge example). It upgrades only if the request-id API the team wants needs a newer crate, and the PR says why.