# Fix Vue Exceptions From PostHog Error Tracking

Yes. An agent reads your top PostHog exception, finds the Vue code that throws it, reproduces it in a test and opens a pull request with the fix.

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

## What the agent does

The agent starts in its own cloud sandbox with your repository cloned and your PostHog project reachable through the PostHog connection, which reads error tracking alongside analytics and feature flags. It lists the error-tracking issues from the last 7 days, sorts them by occurrences and takes the first one. From that issue it keeps the exception type, the message, the first and last time it was seen, the browsers it hit and the stack frames, so the pull request can name exactly what it fixes.

Then it maps the frames to source. In a Vue 3 app like the RealWorld example, it reads `package.json` and finds Vue `^3.5.0`, Pinia `^3.0.0`, vue-router `^5.1.0`, Vite `^8.0.16` and a `bun.lock`, so it installs with Bun. Article state lives in `src/store/article.js`, a Pinia store whose `fetchArticle`, `fetchComments`, `addFavorite` and `destroyComment` actions call `ArticlesService`, `CommentsService` and `FavoriteService` from `src/common/api.service.js`. `src/views/Article.vue` loads both in `beforeRouteEnter` with `.catch(() => null)` on each call, so a failed request leaves the store holding the default article, and the template then hands `article.body` to `parseMarkdown`, which runs `marked.parse` and `DOMPurify.sanitize`. A frame that points into minified Vite output is checked against `vite.config.js`, which sets no `build.sourcemap`; when the frames cannot be matched to a line, the agent says so rather than guessing.

Before it changes anything, the agent reproduces the exception. The repository's only test runner is Playwright (`playwright test`, against `bun run serve` on port 8080, with the shared RealWorld specs under `realworld/specs/e2e`), which is slow for a single store action. So it adds Vitest as a dev dependency and writes a test that drives the failing path directly: the store action with the API response PostHog's issue implies, or the view's markdown step with the value that broke it. It runs `npx vitest run` and keeps the failing output, which is the proof that the test reproduces the reported error and not a different one.

Then it fixes the cause in the store or the view, reruns `npx vitest run` until the new test passes, and runs `bun run lint` (ESLint on `src`) and `vite build` so the change does not break the bundle. It also runs the Playwright suite when the browsers install in the sandbox, because the article page is what those specs cover. It does not silence the exception with a broader `catch`; when the right fix is to show an error state instead of rendering an empty article, it does that and says why in the pull request.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "Use the PostHog connection to list this project's error-tracking issues from the last 7 days and take the one with the most occurrences. Map its stack frames to the source in src/store/article.js, src/views/Article.vue and the components they render. Add Vitest as a dev dependency, reproduce the exception with a test, then fix the cause until `npx vitest run` passes. Run `bun run lint` and `bun run build`, and the Playwright suite if its browsers install. Open a pull request that names the PostHog issue, its occurrence count and first-seen time, quotes the failing test output from before the fix, and explains the cause. Do not hide the error with a broader catch.",
  "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

What comes back is a pull request on a branch the agent created. It changes the store or view where the exception starts, adds the Vitest test that reproduces it, and adds `vitest` to `devDependencies` with the updated `bun.lock`. The description names the PostHog issue with its occurrence count and first-seen time, quotes the test failing before the fix and passing after, and explains in a few sentences why the code threw, such as a store action that leaves `article.body` as `undefined` after a failed request.

Your repository's own checks run on the pull request as they do for any branch. The session also keeps the full record of the run: every command the agent ran in the sandbox with its output, the PostHog queries it made and the files it read, so a reviewer can trace each claim in the description back to the step that produced it.

Before merging, a reviewer checks that the test reproduces the same exception PostHog reported, not a nearby one, that the fix handles the cause rather than catching the error further up, and that the page still behaves sensibly when the API fails, for example by showing an error instead of an empty article. If the reviewer wants a different approach, a follow-up message to the same session asks for it, and the agent continues on the same branch.

## Run it on every new PostHog error-tracking issue

PostHog can call a webhook when error tracking opens a new issue or an issue crosses a threshold. Point it at a small handler on your server that sends this request with the issue's id in the prompt, so each new exception gets its own run and its own pull request instead of waiting in a list.

Set a webhook URL on the API key and Rush POSTs `run.completed` when the turn finishes, with the `session_url`. Your handler can read the session, take the pull request from it and post the link back to the PostHog issue or to your team's channel, so whoever triages errors starts from a proposed fix.

## Why run it on Rush?

Fixing a production exception on a laptop means pulling the error data by hand, guessing which build the stack frames came from, adding a test runner the project does not have and keeping all of that out of whatever else is on the branch. In a Rush sandbox the agent reads PostHog through your connection, installs with Bun, adds Vitest and runs the tests on its own disk, and nothing on your machine changes.

The pull request carries its own proof: the test that failed before the fix, the same test passing after, and the transcript of every command. Several exceptions can be worked at once, one run each, up to the key's concurrent run limit, so the top few issues from the week do not have to wait for one person to get through them in order.

## Frequently asked questions

### How does the agent read my PostHog data?

Connect PostHog once with `POST /me/connections` as an MCP server; it signs in with OAuth. Then name it in the run's `connections` field, or save an agent that names it. A run gets only the connections it or its saved agent names, so the agent never sees PostHog unless you ask.

### My project has no unit tests. Will it still add one?

Yes. The RealWorld app only has Playwright end-to-end specs, so the agent adds Vitest as a dev dependency and writes one focused test for the exception. If you would rather keep a single runner, say so in the prompt and it writes a Playwright spec instead.

### What if PostHog's stack frames point into minified code?

The agent checks whether the build produces source maps, which `vite.config.js` in the RealWorld app does not configure. It maps what it can from function names and the error message, and says in the pull request which frames it could not place. Turning on `build.sourcemap` and uploading the maps to PostHog makes the next run more precise.

### Will it change code unrelated to the exception?

The prompt limits it to the store, the view and the components they render, plus the new test and the `devDependencies` entry. The pull request's diff shows every file it touched, and anything outside that scope is a reason to ask for a revision before merging.