a69eddc081
This fixes #[#9135](https://github.com/zed-industries/zed/issues/9135) by introducing file/results limit to project search. It does this by changing how project search works in multiple ways. User-facing changes: - Number files that are being searched is now limited to 5000 - Number of search results in all files is now limited to 10000 - If a limit is reached, search is stopped and a message is displayed to the user Under the hood, we also reworked `Project::search_local`: - Code has been refactored so that the concurrency-logic is easier to distinguish from the search logic. - We now limit the number of concurrent `open_buffer` operations, since that is being done on the main thread and can lead to beachballs when finding a lot of results. Note for reviewer: @SomeoneToIgnore since you know this code, can you take a look at this? The changes might look bigger than they are in certain places because I only extracted code into functions, but the middle part — the sorting of file paths — has changed in order to avoid too many tasks opening buffers at the same time and making app unresponsive. What's also curious is that I think there was a bug in that we searched ignored entries _twice_: once in `search_snapshots` and then later in the dedicated `search_ignored_entry` function. I changed the `entries()` call in `search_snapshots` so that it's always `false`, but that caused tests to fail (see `test_search_in_gitignored_dirs`). @bennetbo and I think that there's some state in the Project that made the tests pass before, because the last of the 3 assertions in that test only passes when the other two queries run. So we changed the test to be more stateless and included the possible fix in `search_snapshots`. Release Notes: - Fixed project-wide search leading to unresponsive application when searching in ignored files, by limiting the number of files that are searched (to 5000) and the number of overall search results to 10000. Additional performance improvements have also been made in order to offload more work onto a background thread. ([#9135](https://github.com/zed-industries/zed/issues/9135)). --------- Co-authored-by: Antonio Scandurra <antonio@zed.dev> Co-authored-by: Bennet <bennetbo@gmx.de> |
||
|---|---|---|
| .. | ||
| k8s | ||
| migrations | ||
| migrations.sqlite | ||
| src | ||
| .admins.default.json | ||
| .env.toml | ||
| admin_api.conf | ||
| basic.conf | ||
| Cargo.toml | ||
| LICENSE-AGPL | ||
| 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.
Local Development
Detailed instructions on getting started are here.
Deployment
We run two instances of collab:
- Staging (https://staging-collab.zed.dev)
- Production (https://collab.zed.dev)
Both of these run on the Kubernetes cluster hosted in Digital Ocean.
Deployment is triggered by pushing to the collab-staging (or collab-production) tag in Github. The best way to do this is:
./script/deploy-collab staging./script/deploy-collab production
You can tell what is currently deployed with ./script/what-is-deployed.
Database Migrations
To create a new migration:
./script/sqlx migrate add <name>
Migrations are run automatically on service start, so run foreman start again. The service will crash if the migrations fail.
When you create a new migration, you also need to update the SQLite schema that is used for testing.