This allows the registration of such buffers in the project, which is necessary
to correctly support `::save_buffer_as` and opens the door to sharing untitled
buffers with guests in the future.
Note that, for now, this disallows guests to create untitled buffers in the
current window and will create a new window instead. This is because we don't
yet have a global way of allocating a buffer's remote id (nor a way of saving
such buffers in the host's worktree) and we instead rely on the local model ID,
which could clash with the host's buffer IDs.
I think we should revisit this once guests can share their untitled buffers
with the host and other remote peers, as well as once we start keying
operations by entry id.
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>
