Previously, we would simulate disk-based diagnostics finishing after
saving a buffer. However, the language server may produce diagnostics
right after emitting the event, causing the diagnostics status bar item
to not reflect the latest state of the buffer.
With this change, we will instead simulate disk-based diagnostics finishing
after 1s after saving the buffer (only for language servers that
don't have the concept of disk-based diagnostics, such as TypeScript). This
ensures we always reflect the latest state and doesn't cause the UI to flicker
as a result of the LSP sending us diagnostics after every input.
If the host thinks a guest has a buffer that they don't have, the host won't
send it to them when they attempt to open it the next time. This can happen
if the guest disconnected before they received the host's response to an
initial open buffer request.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Any buffers we requested but that haven't been fully sent will cause
outstainding open requests to hang. If we re-request them, any
waiting open requests will resume when the requested buffers finish
being created.
Co-authored-by: Max Brunsfeld <max@zed.dev>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
It's possible that the host was disconnected when attempting to notify
guests of a file save, so we need to transmit this in order to correctly
update the file's mtime.
Next failing seed OPERATIONS=200 SEED=6894
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
When a host sends a buffer to a guest for the first time, they record that
they have done so in a set tied to that guest's peer id. When the guest
reconnects and syncs buffers, they do so under a different peer id, so we
need to be sure we track which buffers we have sent them to avoid sending
them the same buffer twice, which violates the guest's assumptions.
Also, construct remote projects via the room, to guarantee
that the room can manage the projects' sharing lifecycle.
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
Max Brunsfeld