# Reproduce a Bug from a Linear Issue in a Rails App

Yes. An agent investigates the Rails search report, reproduces it against the real search path and returns a tested fix when the bug is confirmed.

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

## What the agent does

The agent starts with the reported query and expected gem, rather than deciding that a dot needs escaping. In `rubygems/rubygems.org`, `app/controllers/searches_controller.rb` sends web queries to `ElasticSearcher`, and `app/controllers/api/v1/searches_controller.rb` uses the same owner for API search. `lib/elastic_searcher.rb` sanitizes input, then builds an OpenSearch query over name, summary and description plus a prefix query on `name.unanalyzed`. The reproduction must identify which surface returns the wrong result.

It follows indexing as well as query construction. `app/models/concerns/rubygem_searchable.rb` defines a pattern analyzer and a keyword subfield for gem names, while `lib/search_query_sanitizer.rb` limits query complexity and handles wildcard patterns. Existing `test/models/concerns/rubygem_searchable_test.rb` already creates `example.rb` and checks that searching `example` returns it. That test does not establish an exact dotted-name lookup, but it prevents the agent from treating punctuation support as wholly absent.

The agent creates a gem and an indexed version through the existing factories and exercises the issue's exact dotted query against a real test search index. `test/functional/searches_controller_test.rb` demonstrates the `SearchKickHelper` and `:reindex` setup used by web search tests. It first records a failing assertion on unchanged code, then fixes the responsible query, sanitizer or analyzer path. Existing range-syntax and malformed-query protections stay covered; removing sanitization to make a name match would broaden the defect into a security problem.

The environment matters to the evidence. `.ruby-version` declares `4.0.6`, and `Gemfile.lock` locks Rails `8.1.3.1`. `CONTRIBUTING.md` names Postgres, Memcached, OpenSearch and Chrome as test dependencies and documents `bin/rails test:all`; `docker-compose.yml` supplies the backing services. The agent runs the targeted search regression before and after the change, then the full suite. If the report does not reproduce on that revision, it returns the tested conditions and missing details rather than claiming a public repository has a seeded bug.

## Start it with one API call

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

```json
{
  "agent": "codex",
  "input": "The supplied Linear issue reports that searching for a gem name containing a dot returns no results. Read the current web/API search controllers, ElasticSearcher, SearchQuerySanitizer, index mappings and existing indexed search tests. Establish the exact query, expected gem, search surface and revision. Create indexed test data using the repository's real search test helpers, write a regression test and record it failing on unchanged code before fixing the cause. Preserve malformed-query and query-complexity protections; do not stub away OpenSearch. Run the targeted regression again with the fix, then bin/rails test:all with the documented Postgres, Memcached, OpenSearch and browser dependencies in the sandbox. Do not load or mutate production data. If the issue cannot be reproduced, report the actual checks and missing details without inventing a failure. For a verified fix, open a pull request linking the supplied Linear issue URL with before/after output.",
  "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 verified result is a PR with an indexed-search regression and a focused source change. It includes the original query, expected gem, affected web or API route and the targeted command's before-and-after output. If an analyzer change requires rebuilding an index, the description identifies that operational consequence without running a production reindex. The full Rails suite result is reported separately from the narrow regression.

The reviewer checks that the new test searches indexed data rather than simply asserting that a query string contains a dot. Existing protections for malformed or expensive searches must remain effective, and yanked-gem filtering must retain its intended behavior. If current code already returns the expected gem, the result is an investigation with revision and setup details. An unavailable OpenSearch service is reported as a dependency failure, never as proof of the reported search bug.

## Run it on every Linear bug labelled gem-search

Your Linear automation copies the bug's exact query, expected result and issue URL into `input` and sends this request to the sessions API with the accessible repository as a resource. Keep production database dumps and user data out of the request. A stable idempotency header handles repeated delivery of the same issue revision. The receiver reads the resulting session answer or handles its completion webhook before posting review material through whatever separate workflow you authorize.

## Why run it on Rush?

Search reproduction needs a database record, an indexed document and the real query behavior. Rush gives the agent a separate sandbox for that test setup, so investigating punctuation does not change your laptop's index or require access to production search. The requested evidence shows whether the failure comes from application behavior or an unavailable dependency, with actual command output retained for inspection.

Different search reports can run independently, each with its own working copy and recorded result. Reviewers can compare the failing assertion, the source fix and the full-suite output instead of accepting an unsupported explanation about escaping. A follow-up after the turn ends can ask the agent to test an API variant or clarify an index migration while preserving the existing investigation context.

## Frequently asked questions

### Does the existing test already cover dotted names?

It creates `example.rb` and checks a token search for `example`. The reported issue needs its exact dotted query and expected result exercised as well. The agent must establish that difference before deciding whether additional coverage exposes a real bug.

### Can the test replace OpenSearch with a stub?

That would omit the analyzer, mapping and query interaction under investigation. The requested reproduction uses the real test index and repository search helpers. A sanitizer-only test can complement that evidence but cannot establish that indexed search returns the right gem.

### Will it rebuild the production search index?

The prompt forbids production data access and asks for sandbox verification. If the verified fix changes index analysis, the PR describes the required rollout consequence for review. Production reindexing requires separate authorization.

### What if the bug no longer reproduces?

The agent reports the revision, test query, indexed data and observed result. It identifies missing conditions instead of manufacturing a failing test or an unnecessary patch. A clear investigation answer is more useful than a PR that cannot demonstrate the original failure.