This could happen because there was a pause between creating the worktree
and adding it to the list of tracked local worktrees, and so we might end
up adding the same worktree twice when calling `create_local_worktree` in
rapid succession.
- 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 reverts commit 4cfd345f9d, because
having a bounded broadcast introduces the possibility of waiting forever
when there isn't yet a receiver processing those events.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
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.
This probably isn't the *root* cause of why an executor is leaked,
but by cutting off this cyclic references, it may make it a bit easier
to track down leaks of an executor.
* 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>
