# Fix Failing GitHub Actions Checks in a Next.js App Yes. When your Next.js build goes red, an agent reads the failed job's log, reruns the same pnpm command, fixes the type or format error and opens a pull request. [Run this on Rush](https://cloud.getrush.ai/run/fix-failing-ci/nextjs/), in a Project that has your repository. ## What the agent does The agent starts with the log, not the code. From the `workflow_run` event it runs `gh run view --log-failed`, names the failing job and step, and quotes the first real error, because a Next.js build log buries it under a page of route output. In an App Router app like vercel/commerce the checks a workflow can run are the ones `package.json` defines: `pnpm build` (`next build`), `pnpm prettier:check`, and `pnpm test`, which in this repository is an alias for the Prettier check. The repository ships no workflow file of its own, so the agent reads yours to see which of those steps ran, on which Node, and with which environment variables. Then it matches the toolchain. The app pins `next` 15.6.0-canary.60 with React 19.0.0, TypeScript 5.8.2 and Prettier 3.5.3 with `prettier-plugin-tailwindcss`, installed with pnpm from `pnpm-lock.yaml`. `tsconfig.json` sets `strict` and `noUncheckedIndexedAccess`, so an array index or a record lookup that a contributor did not guard fails type checking in `next build` rather than at runtime. `next.config.ts` turns on `experimental.ppr`, `inlineCss` and `useCache`, which change what the build type-checks for cached functions. And the build fetches from Shopify: `lib/shopify/index.ts` reads `SHOPIFY_STORE_DOMAIN` and `SHOPIFY_STOREFRONT_ACCESS_TOKEN` from the environment inside `shopifyFetch`, so a job without those secrets fails on data fetching with an error that looks nothing like the commit's change. The agent tells those cases apart from the log before it edits anything. With the failure reproduced in its sandbox with the same command, it reads the code the error names. The cart is the code most pull requests touch: `components/cart/actions.ts` holds the server actions `addItem`, `removeItem`, `updateItemQuantity`, `redirectToCheckout` and `createCartAndSetCookie`, each reading the `cartId` cookie through `cookies()`, calling `addToCart`, `removeFromCart`, `updateCart` or `getCart` from `lib/shopify`, and invalidating with `updateTag(TAGS.cart)` from `next/cache`; `components/cart/cart-context.tsx` keeps the optimistic cart with `useOptimistic` and a reducer over `UPDATE_ITEM` and `ADD_ITEM`. A type error here is usually a `Cart` or `CartItem` field from `lib/shopify/types.ts` that the change assumed present, and the agent fixes it against the GraphQL fragment in `lib/shopify/fragments/cart.ts` rather than with a cast. It fixes the cause, reruns the failing command, then runs the other scripts the workflow runs, `pnpm prettier:check` and `pnpm build`, so the fix for one step does not turn the next one red. Formatting is applied with `pnpm prettier` on the changed files only. If the job failed for a missing secret, the agent changes no code: it says so in its answer, names the variable from `.env.example`, and opens nothing. ## Start it with one API call `POST https://api.prix.dev/o/{org}/sessions` ```json { "agent": "codex", "input": "The GitHub Actions workflow on this branch failed; the workflow_run event is at the end of this prompt. Read the failed job's log with gh run view --log-failed, name the job and step that failed, and quote the first real error (a TypeScript error from next build, a Prettier diff, or a fetch failure from lib/shopify). Read the workflow file to see which package.json scripts it runs and on which Node. Install with pnpm from the lockfile, set the SHOPIFY_* variables from .env.example to placeholder values if the step needs them to start, and reproduce the failure with the same script. Fix the cause in the code (fix a type error against lib/shopify/types.ts and the fragments rather than with a cast; change a test or config only if it is wrong, and say so), then run pnpm prettier:check and pnpm build until both pass, and open a pull request against the failing branch that quotes the error it fixed. If the failure is a missing secret or a Shopify outage rather than code, say so and open no pull request.\n\nEvent: ", "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 A pull request against the failing branch, with the fix in the component, action or `lib/shopify` module the error named and the job, step and quoted error in the description. It shows the command failing and then passing in the sandbox, lists `pnpm prettier:check` and `pnpm build` with their results, and the session's trajectory keeps every command with its full output. The workflow runs again on the pull request. When the log shows a fetch error from `shopifyFetch` rather than a compile error, the answer says which variable the job lacked and opens no pull request, because the fix is in the repository's secrets, not its code. When the failure is a Prettier diff, the pull request is the formatted files and nothing else. A reviewer checks that a type fix narrows the data at the fragment or type definition rather than casting at the use site, that `next.config.ts` and `tsconfig.json` are untouched, and that the change still invalidates the cart tag after each mutation. ## Run it on every failed Next.js build Add an automation to the Project with this prompt and a `github` trigger on `workflow_run.failure`; each failed run of your build workflow starts one run with the event under the prompt, and only work by owners, members and collaborators fires it. Or send GitHub's `workflow_run` webhook to your own server and send this request with `https://github.com///tree/` as the resource. Exclude the agent's own branches so a failed fix does not trigger itself, keep each `workflow_run.id` with the `execution_id` to drop redeliveries, and use the `run.completed` webhook from Rush to post the pull request link on the contributor's pull request. ## Why run it on Rush? A red `next build` is often not what it looks like: a strict-mode type error two files away from the change, a Prettier plugin reordering classes, or a Shopify fetch that only fails where the secret is missing. The agent reads the log for the first real error and reproduces it in its own sandbox with the same pnpm command, without touching your checkout or your `.env`. What comes back is checkable: the quoted error, the trajectory with every `pnpm` run and its output, and the workflow rerunning on the pull request. Several failing branches each get their own run at once, and nothing merges without a reviewer. ## Frequently asked questions ### The repository has no test runner. What does it run? The scripts your workflow runs. In vercel/commerce that is `pnpm build` and `pnpm prettier:check`, since `pnpm test` is an alias for the latter. If your fork added Vitest or Playwright, the agent runs those scripts too, because it reads the workflow file rather than assuming. ### Does it need my Shopify credentials to build? To finish `next build` on pages that fetch at build time, yes, and it does not have them. It sets placeholder values only to get the step to start, reports a fetch failure as a secrets problem rather than a code problem, and never writes a credential into the repository. ### Will it suppress a type error with a cast or a ts-ignore? No. The prompt asks for the fix at the type or the fragment, and a `// @ts-ignore` or an `as any` would show in the diff. Where the data really is optional, it adds the guard where the value is read. ### Can it fix a failure on a canary Next.js version? It installs exactly the version in `pnpm-lock.yaml`, canary included, so it sees the same compiler behavior the runner saw. If the failure comes from the canary itself rather than the change, it says so and does not pin a different version on its own.