When handling this messages on the host, wait until the desired
version has been observed before performing the save.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
On guests, this ensures we never miss updates to subsequent buffers in
the project transaction that arrive while we're waiting for edits on a
prior buffer in the transaction.
Specifically, the test now ensures that the host's worktree observes a/file1's
change event *before* the rename occurs, otherwise when interpreting the change
event it will mistakenly think that the file has been deleted (because its path
has changed) and will subsequently fail to detect the rename, causing the test
to fail.
This way, completions are dealt with more consistently with code actions,
and the logic is not spread across so many places. The `language::File`
trait and the multibuffer no longer need to deal with completions. Completions
are no longer generic over an anchor type.
Using a bounded channel may have blocked the collaboration server
from making progress handling RPC traffic.
There's no need to apply backpressure to calling code within the
same process - suspending a task that is attempting to call `send` has
an even greater memory cost than just buffering a protobuf message.
We do still want a bounded channel for incoming messages, so that
we provide backpressure to noisy peers - blocking their writes as opposed
to allowing them to buffer arbitrarily many messages in our server.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This isn't perfect but we'll retain up to 10 old versions just in case there
are race conditions in the language server. We haven't seen this in the wild
but we're concerned about diagnostic reporting racing with code action
resolution.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This avoids a problem where the operating system would drop events
on the floor and tell us to rescan the entire directory, which in turn
would cause a flicker in the project browser.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This used to be needed, but we think with our improvements to message ordering that we'll never miss operations that were applied after opening a remote buffer.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
