This allows these events to be logged in the Zed client (until we setup tracing there).
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>
- Add a bunch of events to Peer's async connection handling logic
- Use an EnvFilter to allow more control over the verbosity level of tracing on a per-module basis
- Wire up logging to emit trace events (we actually probably want to do this the other way around)
Co-Authored-By: Antonio Scandurra <me@as-cii.com>
* Be sure we send updates to multiple clients for the same user
* Be sure we send a full contacts update on initial connection
As part of this commit, I fixed an issue where we couldn't disconnect and reconnect in tests. The first disconnect would cause the I/O future to terminate asynchronously, which caused us to sign out even though the active connection didn't belong to that future. I added a guard to ensure that we only sign out if the I/O future is associated with the current connection.
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.
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>
We have an hypothesis that the server gets stuck while processing
an incoming message, either because the buffer fills up or because
a handler never completes. This should mitigate that and, once we
add logging, give us some clue as to what is causing it exactly.
Co-Authored-By: Nathan Sobo <nathan@zed.dev>
Max Brunsfeld