* Make `UnregisterProject` a request. This way the client-side project can wait
to clear out its remote id until the request has completed, so that the
contacts panel can avoid showing duplicate private/public projects in the
brief time after unregistering a project, before the next UpdateCollaborators
message is received.
* Remove the `RegisterWorktree` and `UnregisterWorktree` methods and replace
them with a single `UpdateProject` method that idempotently updates the
Project's list of worktrees.
We were calling `next` twice, which led us to skip every other entry.
This commit also enhances the `test_share_project` integration test
to exercise this new streaming logic.
This ensures that entries don't randomly re-appear on remote worktrees
due to observing an update too late. In fact, it ensures that the remote
worktree has the same starting state of the host before preemptively applying
the fs operation locally.
This is related to #849: in that pull request we avoided *storing*
empty diagnostics, but we'd still report an event when receiving
consecutive empty diagnostics. So if the project diagnostics editor
was open, it could happen that opening a buffer would cause the
language server to report zero diagnostics. We would therefore close
the buffer because there were no diagnostics, but doing so would cause
the LSP to report another event with zero diagnostics. This would repeat
forever, causing Zed to use a lot of CPU and the UI not to refresh properly.
With this commit we will simply avoid emitting a `DiagnosticsUpdated` event
altogether if no diagnostics were present before *and* the LSP is reporting
a `PublishDiagnostics` event with no diagnostics in it.
When opening a buffer, some language servers might start reporting
diagnostics. When closing a buffer, they might report that no diagnostics
are present for that buffer. Previously, we would keep an empty summary entry
which would cause us to open a buffer in the project diagnostics view, only to
drop it because it contained no diagnostics. However, the act of opening it
caused the language server to asynchronously report non-empty diagnostics.
We would therefore handle this as an update, but the previous closing of the
buffer would cause the language server to report empty diagnostics again. This
would cause the project diagnostics view to thrash infinitely between these two
states, pegging the CPU and constantly refreshing the UI.
With this commit we won't maintain empty summary entries for files that contain
no diagnostics, which fixes the above issue.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
This fixes an error in the randomized test that would cause the future
returned from `Worktree::share` to never finish due to a bug in `postage`
that causes its waker to not be notified upon drop.
Previously, we weren't fully clearing the state associated with projects and worktrees when losing connection. This caused us to not see guest avatars disappear and not be able to re-share upon reconnect.
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Previously, we tracked the worktree_id and entry_id separately, but now that entry ids are unique across all worktrees this is unnecessary.
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-Authored-By: Keith Simmons <keith@the-simmons.net>
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.
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>
