situation

# 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](https://perfloop.ai/t/oss/case_mtzbwvz133): 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](https://perfloop.ai/t/oss/case_rh9qgdtpp8): 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](https://perfloop.ai/t/oss/case_c7zssat97s): 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](https://perfloop.ai/docs/work/quickstart).