Concurrency bugs in Go and Rust

The Cases below cover waits across goroutines and tasks. Each records the ordering tested and the evidence behind the change.

The workflow

1. Connect your repos in Setup. A model build reads them and proposes hypotheses.
2. Open a Case and select Work this case. Your coding agent can also submit a branch for review through the MCP server.
3. Perfloop writes the change and a check of the claim. When the claim names the original code as its comparison, the check must fail there and pass with the change.

Public Cases

• Tigris TAG, Go: the stream could close only after a cache-completion wait ended. Removing the wait reduced median cacheable GET-miss handler time from 101.2 ms to 0.57 ms. Verified and merged upstream.
• Dolt, Go: closing a keyless index scan early could leave its producer goroutine blocked on a full channel. Validated by a different change, merged upstream.
• Codex, Rust: coalescing queued file-search queries reduced median time to the current result from 329 ms to 150 ms during query bursts over 32,768 files. Verified; no upstream pull request is recorded.

What it cannot do

Perfloop opens pull requests, and issues for results better filed as an issue. It cannot approve, merge, or deploy. A proven result opens nothing until a member selects Approve & open PR or Approve & open issue in Inbox, unless that repo's Pull requests control is on. When your repo's rules hold a result, the hold shows on its Case page instead. A hypothesis the evidence disproves is recorded as refuted, and its record stays. Start with the Quickstart.