# Reproduce a Bug from a Linear Issue in a Next.js App

Yes. An agent investigates the reported Next.js date-range bug, writes a reproduction test and proposes a fix with before-and-after evidence.

[Run this on Rush](https://cloud.getrush.ai/run/reproduce-linear-bug/nextjs/), in a Project that has your repository.

## What the agent does

The agent treats the Linear report as a hypothesis: the date picker shows the wrong week when the browser is ahead of UTC. In `umami-software/umami`, `src/components/input/DateFilter.tsx` represents This Week as `0week`, while `src/components/metrics/DatePickerForm.tsx` serializes custom selections as `range:` values containing timestamps. Those are different paths. It first records the selected option, browser zone, configured reporting zone and locale, so a failing custom-date test cannot be presented as a reproduction of the week shortcut.

It follows the shortcut through `src/components/hooks/useDateRange.ts` into `src/lib/date.ts`. The parser accepts a timezone and uses `toZonedTime` when one is supplied, then computes week boundaries with locale-aware `startOfWeek` and `endOfWeek`. `src/components/hooks/useDateParameters.ts` passes the configured timezone into that hook and converts boundaries through `useTimezone`. This is a path to investigate, not proof of a defect; the agent must establish which conversion or caller disagrees with the issue's expected week.

`src/lib/date.test.ts` already fixes the clock with Vitest and tests week calculations. The new reproduction chooses a fixed instant near a week boundary, an explicit positive-offset browser timezone and independently stated expected dates. It distinguishes locale-defined week starts from timezone conversion. The agent records the failure on unchanged application code before fixing the responsible owner. If the current revision already behaves correctly, it reports that finding and the missing reproduction details instead of inventing a seeded bug or forcing a code change.

`package.json` declares Next.js `16.3.4`, a pnpm engine of `12.3.4`, a `pretest` step generating the Prisma client and `test: vitest run`. `vitest.config.ts` includes source tests and uses jsdom. The agent runs the narrow regression first, then `pnpm test` for the full configured suite, preserving the same time and zone settings for the before-and-after comparison. Browser reproduction, if performed, is recorded separately from a helper test and includes the environment that makes the symptom visible.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "The supplied Linear bug report says the date-range picker shows the wrong week when the browser timezone is ahead of UTC. Investigate the actual selected option, locale, browser timezone and reporting timezone before diagnosing. Trace DateFilter, DatePickerForm, useDateRange, useDateParameters, useTimezone and the shared date helpers in the current repository. Write a deterministic regression test with a fixed instant and independently specified expected boundaries. Run it against unchanged application code and keep the failing output before fixing the source; then show the same test passing and run the full pnpm test suite, including its Prisma generation prerequisite. Do not invent a bug or a failing baseline if the current revision does not reproduce it: report the revision, checks and missing details instead. Open a pull request for a verified fix linking the supplied issue URL, with before/after evidence and explicit limits on browser verification.",
  "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

For a reproduced defect, the PR contains a regression test and the smallest change to the responsible date path. The description states the browser zone, reporting zone, locale and fixed instant, then includes the observed failure before the fix and success afterward. Full-suite output is listed separately. A formatting change or a screenshot without the environment cannot substitute for the requested causal evidence.

The reviewer checks that the expected boundaries come from the issue's intended calendar behavior rather than being recomputed with the same helper under test. They inspect downstream timestamps as well as the displayed week, and verify that changing the browser zone does not silently change the reporting-zone contract. If reproduction fails, the result is an investigation answer with commands and missing inputs, not a fabricated fix PR. No successful run or test count is implied by this example page.

## Run it on every Linear bug labelled date-range

Have your webhook receiver copy the issue's reproduction steps and URL into `input` and send the repository in `resources` to the sessions API. Include the reported timezone and locale rather than assuming the agent can infer them from a screenshot. An `Idempotency-Key` scoped to the issue revision prevents duplicate starts on webhook retries. Your receiver can wait for a completion webhook and read the session answer before deciding whether the issue has enough evidence for a fix.

## Why run it on Rush?

Timezone bugs need controlled execution conditions that can differ from the developer's laptop. Rush gives the agent a separate sandbox for fixed-clock tests and explicit zone settings while leaving your machine's timezone and current Next.js branch alone. The requested transcript preserves the environment and command output, so a reviewer can inspect how the reproduction was established.

Separate reports can run as independent sessions, each with its own repository state and evidence. That avoids mixing a date-picker investigation with another task's changes or test clock. Read the final answer through the session endpoint and the command history through messages, then send a follow-up after the turn finishes if the issue needs a different locale or an additional reporting-zone case.

## Frequently asked questions

### Does the public example definitely contain this bug?

This page makes no such claim. The inspected repository provides the real date-selection and test paths for investigating the report. The request requires reproduction on the actual revision before a fix is proposed.

### Why test both browser and reporting timezones?

The application passes a configured timezone into date-range parsing and later converts boundaries for requests. A browser ahead of UTC does not by itself identify which part of that contract is wrong. The reproduction must state both zones and the selected range.

### What proves that the test reproduced the issue?

The same regression test must fail on unchanged application code for the reported behavior and pass with the fix. Its expected result should be specified independently of the implementation helper. A failing import or missing generated Prisma client is a setup failure, not a reproduction.

### Will it change every date calculation?

The prompt asks for the smallest verified source fix. Other shortcuts and custom ranges need regression checks when they share the changed path. A broad date-library replacement would require separate evidence and scope.