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.
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.
Refactor HTTP and github release downloading into util
Lazily download / upgrade the copilot LSP from Zed
Co-authored-by: Max <max@zed.dev>
Co-Authored-By: Antonio <antonio@zed.dev>
The worktree no longer pulls the background snapshot from the background scanner.
Instead, the background scanner sends both snapshots to the worktree. Along with
these, it sends the path change sets.
Also, add randomized test coverage for the worktree UpdatedEntries events.
* Consolidate local worktree construction into one method
* Simplify remote worktree construction
* Reduce indirection around pulling worktree snapshots from the background
We need to know the most recent scan id we have actually completed. This is to
handle the case where a guest disconnects when we're in the middle of streaming
worktree entries to them. When they reconnect, they need to report a scan_id
from before we started streaming the entries, because we have no record of when
the stream was interrupted.
Next failure:
SEED=5051 ITERATIONS=1 OPERATIONS=200 cargo test --release --package=collab random -- --nocapture
Previously, the protocol used a mix of strings and bytes without any consistency.
When we go to multiple platforms, we won't be able to mix encodings of paths anyway.
We don't know this is the right approach, but it at least makes things consistent
and easy to read in the database, on the wire, etc. Really, we should be using entry
ids etc to refer to entries on the wire anyway, but there's a chance this is the
wrong decision.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
