mirror of
https://github.com/coder/coder.git
synced 2026-10-16 14:48:56 +08:00
Danielle Maywood
e981ff4eec
A git watch `refresh` only rescanned the repos already being watched. A path recorded before its repo existed, for example before `git init`, or a repo that was deleted and recreated, stayed hidden until the client reconnected, so a page reload showed repos the refresh button didn't. Refresh now resolves the chat's paths again, as a new connection does. The first scan of a connection is also sent even when no repos are watched, so a client can replace state left over from an earlier connection; later scans with no repos still send nothing. ### Before https://github.com/user-attachments/assets/33bf9046-0448-4537-9a97-c97f51e1cc39 ### After https://github.com/user-attachments/assets/82b15d03-6460-4fe0-b5e7-b4bafbbd72d1 <details> <summary>Decision log</summary> The git panel's refresh button should show everything a page reload would. Investigation found five ways it didn't, each fixed in its own PR on the current `changes` protocol: 1. `execute` without a workdir didn't record the directory the process ran in (`agent/agentproc`). 2. Refresh only rescanned repos already being watched, so a repo created or recreated after its path was recorded stayed hidden (`agent/agentgit`). A connection with no repos also got no first message. 3. After a git watch reconnect, the new full state was merged into the previous connection's map, so deleted repos stayed visible (`useGitWatcher`). 4. A chat watch reconnect didn't refetch the open chat, so missed `diff_status_change` events were lost (`AgentsPageLayout`). 5. Refresh didn't refetch the chat, whose diff statuses back the PR tabs, and was disabled until git context existed (`GitPanel`, `AgentChatPageView`). Considered and deferred: a snapshot protocol with diffs fetched by hash, which would keep large multi-repo diffs under the 4 MiB proxy read limit, and making scans faster at scale. Neither is needed to fix refresh, and together they made a single ~5900-line change that couldn't be reviewed. The refresh spinner still runs for a fixed time, since tying it to the response needs a request ID in the protocol. </details> --- _Generated by Coder Agents on behalf of @DanielleMaywood._