mirror of
https://github.com/zed-industries/zed.git
synced 2025-01-11 21:13:02 +00:00
d36a4888db
Changing the frequency at which we update worktrees highlighted a problem in the randomized tests that was causing clients to receive a definition to a worktree *before* observing the registration of the worktree itself. This was most likely caused by #1224 because the scenario that pull request enabled was the following: - Guest requests a definition pointing to a non-existant worktree - Server forwards the request to the host - Host sends an `UpdateProject` message - Host sends a response to the definition request - Server observes the `UpdateProject` message and tries to acquire the store - Given that we're waiting, the server goes ahead to process the response for the definition request, responding *before* `UpdateProject` is forwarded - Server finally forwards `UpdateProject` to the guest This commit ensures that, after forwarding a project request and getting a response, we acquire a lock to the store again to ensure the project still exists. This has the effect of ordering the forwarded request *after* any message that was received prior to the response and for which we are still waiting to acquire a lock to the store. |
||
|---|---|---|
| .. | ||
| k8s | ||
| migrations | ||
| src | ||
| .env.template.toml | ||
| basic.conf | ||
| Cargo.toml | ||
| Procfile | ||
| README.md | ||
Zed Server
This crate is what we run at https://collab.zed.dev.
It contains our back-end logic for collaboration, to which we connect from the Zed client via a websocket after authenticating via https://zed.dev, which is a separate repo running on Vercel.