GeezerVison

Summary

A chat can now track more than one pull request. Each git ref that the agent reports gets its own row. The git panel shows one view per ref.

Problem

The chat_diff_statuses table had one row per chat. Because of this, a chat could show data for only one pull request at a time. When a chat switched from one branch to another, the old branch's pull request data stayed with the new branch. The old data also hid pull requests for other repos in the same workspace.

Fix

• The table key is now (chat_id, git_remote_origin, git_branch). Each ref keeps its own row and its own pull request data. A branch switch adds a new row. It does not change the old row.
• The worker polls only the ref that the chat last reported. Older refs of the same origin stop polling but keep their data. They resume when the agent reports them again.
• The worker looks for a new open pull request when the stored one is merged or closed. If no new one exists, the old data stays.
• The API has a new diff_statuses list next to the old diff_status field. The old field keeps its meaning: the server picks the most recently refreshed open pull request, and falls back to a merged or closed one. No API field was removed or changed.
• diff_status_change events have a new changed_diff_status field that names the ref that changed. The chat in the event keeps the primary pick in diff_status.
• GET /chats/{chat}/diff has new optional origin and branch query parameters. When you do not send them, the endpoint acts as before. The endpoint no longer writes to the database on read.
• The git panel shows one view per tracked ref. Each view loads its own diff with the ref selector.

Notes for review

• Migration 000590 swaps the primary key. No data rewrite is needed: the old key allowed only one row per chat, so all rows satisfy the new key. The index build takes an ACCESS EXCLUSIVE lock for its duration. CREATE INDEX CONCURRENTLY is not possible because all migrations run in one transaction. Deployments must stop old coderd instances before the migration runs: their ON CONFLICT (chat_id) writes fail once the old key is gone.
• The frozen rows use a far-future stale_at instead of 'infinity': the pq driver in this repo cannot read 'infinity' into time.Time.
• The acquisition query now claims rows by the full key. The old query claimed every row of a chat when any one of them went stale.
• Multi-repo workspaces only track refs that reach the askpass flow. Full coverage of repos that never prompt for credentials needs separate agent-side work.

Generated by Coder Agents.