# Fix a NestJS API Bug From a Datadog Monitor Alert

Yes. A Datadog monitor starts a run; the agent reads the logs and traces, fixes the NestJS module with a Jest test and opens a pull request quoting them.

[Run this on Rush](https://cloud.getrush.ai/run/fix-datadog-alerts/nestjs/), in a Project that has your repository.

## What the agent does

The agent reads the monitor through the Datadog connection, then the error logs and APM traces for the service in the 30 minutes around the alert. Datadog's Node tracer instruments Express under NestJS, so each trace names the route, such as `POST /api/v1/auth/refresh`, and the error span carries the exception. A rise in 401s on the refresh route reads very differently from a rise in 500s, and the agent counts both before it opens any code.

In a NestJS API like `brocoders/nestjs-boilerplate`, auth lives in `src/auth/`: `auth.controller.ts` maps the routes and `auth.service.ts` holds the logic, `validateLogin`, `register`, `confirmEmail`, `forgotPassword`, `resetPassword`, `refreshToken`, `logout` and more. `refreshToken` hashes a new random value, calls `sessionService.updateByHash` with the session id and the old hash, and throws `UnauthorizedException` if no session matched or the user has no role. Users live in `src/users/`, with `users.service.ts` over a repository that has both `relational` (TypeORM) and `document` implementations under `infrastructure/persistence/`. The agent checks which one the service runs before it trusts a stack trace.

It reproduces the failure in a Jest test. The project's `jest` config in `package.json` sets `rootDir` to `src` and runs files matching `.spec.ts`, so `npm test` picks up a new `src/auth/auth.service.spec.ts` built with `Test.createTestingModule` and the real service, with only the session and user repositories replaced. The end-to-end suites in `test/user/auth.e2e-spec.ts` need the API and a database running, through `npm run test:e2e` with `env-cmd`, and the agent runs them with the project's Docker Compose files when the fix touches a route's contract.

With the test failing for the right reason, it fixes the service, runs `npm test` and opens a pull request that quotes the log lines and trace, links the monitor, and says what the bug did to users: for example, logging them out early or letting a used refresh token succeed twice.

## Start it with one API call

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

```json
{
  "agent": "codex",
  "input": "A Datadog monitor on this NestJS service fired; its webhook payload follows this prompt. Use the Datadog connection to read the monitor and the error logs and APM traces from the 30 minutes around the alert, counting status codes per route. Find the code path that produced them in the auth and users modules, src/auth/auth.service.ts and src/users/, and check which persistence implementation is in use. Write a Jest regression test as a .spec.ts file under src/ using Test.createTestingModule, fix the code, run npm test, and run npm run test:e2e as well if the fix changes a route's behaviour. Open a pull request that quotes the log lines the fix addresses and links the monitor.\n\nMonitor payload:\n{payload}",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ],
  "connections": [
    "datadog"
  ]
}
```

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

A pull request comes back with the fix in a NestJS provider, usually `auth.service.ts` or the session or users service it calls, and a new `.spec.ts` file that `npm test` now runs. The description quotes the logs and the route from the trace, links the monitor and lists the test commands with their summary lines. If the end-to-end suite ran, its result is in the description too.

The session's `result`, delivered in `data.result` on the `run.completed` webhook, explains the cause in a few sentences. The transcript records the Datadog queries, the Docker Compose setup if one ran and every Jest run, so a reviewer can see which tests passed on which database.

For an auth fix, the reviewer checks more than the green test: that a refresh token still works once and only once, that a deleted or role-less user is still refused, and that the fix changes no response shape a client depends on. Those are the cases the new spec should cover, and the review is the place to ask for one that is missing.

## Run it on every Datadog monitor alert

Set up an automation with a webhook trigger in the Project for this API, with this prompt and a saved agent that names your Datadog connection. Datadog's Webhooks integration posts to the trigger URL with the trigger secret as the bearer token whenever a monitor message mentions `@webhook-<name>`, and the alert body follows the prompt.

If your platform team prefers its own relay, accept Datadog's webhook there and call `POST /o/{org}/sessions` with this request, the payload in `input` and the alert id as `Idempotency-Key`. A key allows `max_concurrent` runs at once, 4 by default, and answers `429` beyond that.

## Why run it on Rush?

Auth bugs are urgent and easy to fix wrongly. A Rush run takes the time a tired person would not: it reads the traces with your Datadog connection, clones the repository, builds the testing module, and runs Jest and, when needed, the end-to-end suite against a real database in its own sandbox. Every command and its output stay with the session.

Each alert gets a separate run and branch, so an auth monitor and a users monitor firing together do not block each other. The pull request carries the production evidence and the test, and the reviewer decides with the transcript in hand.

## Frequently asked questions

### My project has no unit tests yet. Is that a problem?

No. The agent adds the first `.spec.ts` file where Jest's `rootDir` and `testRegex` already look, so `npm test` runs it with no config change. The pull request says it added one.

### Can it run the e2e tests that need Docker?

Yes, when the prompt allows it. The sandbox is a full computer, so the agent can bring up the project's Compose files for Postgres and run `npm run test:e2e` against them.

### Will it touch real user sessions?

No. It reads logs and traces from Datadog, and works on a clone with test data. Production sessions change only when someone deploys the merged fix.

### What if the monitor is about latency, not errors?

Change the prompt to read the slow traces instead of error logs. The agent then looks for the query or call that takes the time and proposes a fix with a test that pins the behaviour.