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.
We have the ability to define environment-specific environment variables, but don't current need it. This keeps these files in place while avoiding noise from running `export` with no args due to the files being empty.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
We hold these locks for a short amount of time anyway, and using an
async lock could cause parallel sends to happen in an order different
than the order in which `send`/`request` was called.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
