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>
* Don't send a chat message before the previous chat message
is acknowledged.
* Fix emitting of notifications in RPC server
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* On the server, spawn a separate task for each incoming message
* In the peer, eliminate the barrier that was used to enforce ordering
of responses with respect to other incoming messages
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
When the host returns an error after a server has forwarded a request,
we want to surface that error to the guest. At the moment, the server
just returns early leaving some requests unresponded on the guest.
I started auditing all the code paths where we do that, but I am
wondering whether there's some other approach that would prevent us
from repeating this mistake in other code paths.
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.
Also, use env_logger consistently in the tests for each crate.
Only initiallize the logger at all if some RUST_LOG env var is set.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
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>
The former always adds a worktree, even if we have one already in the
project and that could be misused. The public API should always search
for a local worktree containing the requested path first so that the
project can uphold invariants about which worktrees it has.
