The scan_id needs to be bumped even if a scan is already in progress,
so that worktree updates can detect that entries have changed. This
means that the worktree's completed_scan_id may increase by more than
one at the end of a scan.
Previously, we could end up with a situation where the host did not
see an operation but a guest that didn't have that buffer open would. When
such guest would finally open the buffer, they would apply the operation
without however sending it to the host. The guest wouldn't bother resyncing
it because it wasn't part of its open buffers.
Previously, if the client was disconnected while the initial worktree
state was being sent, it would not see the remaining state after reconnecting.
This was due to `scan_id` and `completed_scan_id` both being initialized to
`0`, so the client would ask for updates since `0` and get nothing.
This commit changes the worktree to initialize `scan_id` to `1` and
`completed_scan_id` to `0`, so that we get the full worktree again on reconnect.
Previously, because UpdateProject messages were sent in a separately-
spawned task, they could be sent after CreateBufferForPeer messages that
were intended to be sent after them.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
In `refresh_entry`, we send a message to the `self.path_changes_tx` channel
to notify the background thread that a path has changed. However, given that
`refresh_entry` uses `spawn_weak`, the worktree could get dropped before sending
the message, which could cause a panic.
This commit changes the code to return an error instead of panicking.
Check if the buffer already exists *before* overwriting it.
Ignore redundant registrations on remote projects.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
This fixes a bug where the host would momentarily disconnect and the guest
would close and reopen the project. This would cause the host to not observe
the guest closing the project. When the guest tried to open one of the
buffers opened prior to closing the project, the host would not send them the
buffer state because it would still remember that the buffer was shared.
The `shared_buffers` map is now cleared when the host reconnects and will slowly
get re-filled as guests issue `SynchronizeBuffers` requests.
