* Make advance_clock more realistic by waking timers in order,
instead of all at once.
* Don't advance the clock when simulating random delays.
Co-Authored-By: Keith Simmons <keith@zed.dev>
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
When a network connection is lost without being explicitly closed by the
other end, writes to that connection will error, but reads will just wait
indefinitely.
This allows the tests to exercise our heartbeat logic.
- On the host, ensure that only one worktree can exist for a given absolute
path. Asserting about buffers was cool but I think should be tackled in the
context of leaning more on entry ids for collaboration (vs. buffer ids).
- On the guest, ensure that all the opened buffers don't contain deferred
operations.
This allows us to drop the context *after* we ran all futures to
completion and that's crucial otherwise we'll never drop entities
and/or flush effects.
* Since regular editors' font sizes and families are controlled by
the settings and not the theme, don't store a dummy text style in
the theme. Instead, only store a font color, and synthesize
the text style for regular editors using both the theme and the
settings.
* Style single-line and auto-height editors (now called "field
editors") using a single function that takes the entire theme and
selects a relevant sub-object.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
* Avoid panic when registering a buffer that was previously open,
and whose weak handle was still present in the open_buffers map.
* Avoid releasing any buffers while a request is outstanding which
could return a reference to a buffer.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Instead, create an empty worktree on guests when a worktree is first *registered*, then update it via an initial UpdateWorktree message.
This prevents the host from referencing a worktree in definition RPC responses that hasn't yet been observed by the guest. We could have waited until the entire worktree was shared, but this could take a long time, so instead we create an empty one on guests and proceed from there.
We still have randomized test failures as of this commit:
SEED=9519 MAX_PEERS=2 ITERATIONS=10000 OPERATIONS=7 ct -p zed-server test_random_collaboration
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
We don't need this anymore because worktree updates are foreground
messages.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Co-Authored-By: Max Brunsfeld <max@zed.dev>
Also, add completion requests to the randomized collaboration integration test,
to demonstrate that this is valid.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Some types of messages, which entail state updates on the host, should be
processed in the order that they were sent. Other types of messages should
not block the processing of other messages.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
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>
