This PR adds the following new columns to the `billing_subscriptions`
table:
- `orb_subscription_status`
- `orb_current_billing_period_start_date`
- `orb_current_billing_period_end_date`
Release Notes:
- N/A
This PR makes the `stripe_subscription_id` and
`stripe_subscription_status` columns nullable on the
`billing_subscriptions` table.
Release Notes:
- N/A
Closes #ISSUE
Adds `merge_message` field to the `UpdateRepository` proto message so
that suggested merge messages are displayed in remote projects.
Release Notes:
- git: Fixed an issue where suggested merge commit messages would not
appear for remote projects
This PR updates the `admin` column on the `users` table to be
non-nullable.
We were already treating it like this in practice.
All rows in the production database already have a value for the `admin`
column.
Release Notes:
- N/A
Before, each time any LSP feature was used on client remote, it always
produced a `proto::` request that always had been sent to the host, from
where returned as an empty response.
Instead, propagate more language server-related data to the client,
`lsp::ServerCapability`, so Zed client can omit certain requests if
those are not supported.
On top of that, rework the approach Zed uses to query for the data
refreshes: before, editors tried to fetch the data when the server start
was reported (locally and remotely).
Now, a later event is selected: on each `textDocument/didOpen` for the
buffer contained in this editor, we will query for new LSP data, reusing
the cache if needed.
Before, servers could reject unregistered files' LSP queries, or process
them slowly when starting up.
Now, such refreshes are happening later and should be cached.
This requires a collab DB change, to restore server data on rejoin.
Release Notes:
- Fixed excessive LSP requests sent during remote sessions
Trying to delete a user record from our admin panel throws the following
error:
`update or delete on table "users" violates foreign key constraint
"access_tokens_user_id_fkey" on table "access_tokens"
Detail: Key (id)=(....) is still referenced from table "access_tokens".`
We need to add a cascade delete to the `access_tokens` table.
Release Notes:
- N/A
Release Notes:
- Added channel reordering for administrators (use `cmd-up` and
`cmd-down` on macOS or `ctrl-up` `ctrl-down` on Linux to move channels
up or down within their parent)
## Summary
This PR introduces the ability for channel administrators to reorder
channels within their parent context, providing better organizational
control over channel hierarchies. Users can now move channels up or down
relative to their siblings using keyboard shortcuts.
## Problem
Previously, channels were displayed in alphabetical order with no way to
customize their arrangement. This made it difficult for teams to
organize channels in a logical order that reflected their workflow or
importance, forcing users to prefix channel names with numbers or
special characters as a workaround.
## Solution
The implementation adds a persistent `channel_order` field to channels
that determines their display order within their parent. Channels with
the same parent are sorted by this field rather than alphabetically.
## Implementation Details
### Database Schema
Added a new column and index to support efficient ordering:
```sql
-- crates/collab/migrations/20250530175450_add_channel_order.sql
ALTER TABLE channels ADD COLUMN channel_order INTEGER NOT NULL DEFAULT 1;
CREATE INDEX CONCURRENTLY "index_channels_on_parent_path_and_order" ON "channels" ("parent_path", "channel_order");
```
### RPC Protocol
Extended the channel proto with ordering support:
```proto
// crates/proto/proto/channel.proto
message Channel {
uint64 id = 1;
string name = 2;
ChannelVisibility visibility = 3;
int32 channel_order = 4;
repeated uint64 parent_path = 5;
}
message ReorderChannel {
uint64 channel_id = 1;
enum Direction {
Up = 0;
Down = 1;
}
Direction direction = 2;
}
```
### Server-side Logic
The reordering is handled by swapping `channel_order` values between
adjacent channels:
```rust
// crates/collab/src/db/queries/channels.rs
pub async fn reorder_channel(
&self,
channel_id: ChannelId,
direction: proto::reorder_channel::Direction,
user_id: UserId,
) -> Result<Vec<Channel>> {
// Find the sibling channel to swap with
let sibling_channel = match direction {
proto::reorder_channel::Direction::Up => {
// Find channel with highest order less than current
channel::Entity::find()
.filter(
channel::Column::ParentPath
.eq(&channel.parent_path)
.and(channel::Column::ChannelOrder.lt(channel.channel_order)),
)
.order_by_desc(channel::Column::ChannelOrder)
.one(&*tx)
.await?
}
// Similar logic for Down...
};
// Swap the channel_order values
let temp_order = channel.channel_order;
channel.channel_order = sibling_channel.channel_order;
sibling_channel.channel_order = temp_order;
}
```
### Client-side Sorting
Optimized the sorting algorithm to avoid O(n²) complexity:
```rust
// crates/collab/src/db/queries/channels.rs
// Pre-compute sort keys for efficient O(n log n) sorting
let mut channels_with_keys: Vec<(Vec<i32>, Channel)> = channels
.into_iter()
.map(|channel| {
let mut sort_key = Vec::with_capacity(channel.parent_path.len() + 1);
// Build sort key from parent path orders
for parent_id in &channel.parent_path {
sort_key.push(channel_order_map.get(parent_id).copied().unwrap_or(i32::MAX));
}
sort_key.push(channel.channel_order);
(sort_key, channel)
})
.collect();
channels_with_keys.sort_by(|a, b| a.0.cmp(&b.0));
```
### User Interface
Added keyboard shortcuts and proper context handling:
```json
// assets/keymaps/default-macos.json
{
"context": "CollabPanel && not_editing",
"bindings": {
"cmd-up": "collab_panel::MoveChannelUp",
"cmd-down": "collab_panel::MoveChannelDown"
}
}
```
The CollabPanel now properly sets context to distinguish between editing
and navigation modes:
```rust
// crates/collab_ui/src/collab_panel.rs
fn dispatch_context(&self, window: &Window, cx: &Context<Self>) -> KeyContext {
let mut dispatch_context = KeyContext::new_with_defaults();
dispatch_context.add("CollabPanel");
dispatch_context.add("menu");
let identifier = if self.channel_name_editor.focus_handle(cx).is_focused(window) {
"editing"
} else {
"not_editing"
};
dispatch_context.add(identifier);
dispatch_context
}
```
## Testing
Comprehensive tests were added to verify:
- Basic reordering functionality (up/down movement)
- Boundary conditions (first/last channels)
- Permission checks (non-admins cannot reorder)
- Ordering persistence across server restarts
- Correct broadcasting of changes to channel members
## Migration Strategy
Existing channels are assigned initial `channel_order` values based on
their current alphabetical sorting to maintain the familiar order users
expect:
```sql
UPDATE channels
SET channel_order = (
SELECT ROW_NUMBER() OVER (
PARTITION BY parent_path
ORDER BY name, id
)
FROM channels c2
WHERE c2.id = channels.id
);
```
## Future Enhancements
While this PR provides basic reordering functionality, potential future
improvements could include:
- Drag-and-drop reordering in the UI
- Bulk reordering operations
- Custom sorting strategies (by activity, creation date, etc.)
## Checklist
- [x] Database migration included
- [x] Tests added for new functionality
- [x] Keybindings work on macOS and Linux
- [x] Permissions properly enforced
- [x] Error handling implemented throughout
- [x] Manual testing completed
- [x] Documentation updated
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This PR updates the `billing_subscriptions` table with some new columns
- `kind` - The kind of the description (used to denote Zed Pro vs
existing)
- `stripe_current_period_start` - The Stripe timestamp of when the
subscriptions current period starts
- `stripe_current_period_end` - The Stripe timestamp of when the
subscriptions current period ends
Release Notes:
- N/A
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR updates our DB schemas and wire protocol to separate the
synchronization of git statuses and other repository state from the
synchronization of worktrees. This paves the way for moving the code
that executes git status updates out of the `worktree` crate and onto
the new `GitStore`. That end goal is motivated by two (related) points:
- Disentangling git status updates from the worktree's
`BackgroundScanner` will allow us to implement a simpler concurrency
story for those updates, hopefully fixing some known but elusive bugs
(upstream state not updating after push; statuses getting out of sync in
remote projects).
- By moving git repository state to the project-scoped `GitStore`, we
can get rid of the duplication that currently happens when two worktrees
are associated with the same git repository.
Co-authored-by: Max <max@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
### DISCLAIMER
> As of 6th March 2025, debugger is still in development. We plan to
merge it behind a staff-only feature flag for staff use only, followed
by non-public release and then finally a public one (akin to how Git
panel release was handled). This is done to ensure the best experience
when it gets released.
### END OF DISCLAIMER
**The current state of the debugger implementation:**
https://github.com/user-attachments/assets/c4deff07-80dd-4dc6-ad2e-0c252a478fe9https://github.com/user-attachments/assets/e1ed2345-b750-4bb6-9c97-50961b76904f
----
All the todo's are in the following channel, so it's easier to work on
this together:
https://zed.dev/channel/zed-debugger-11370
If you are on Linux, you can use the following command to join the
channel:
```cli
zed https://zed.dev/channel/zed-debugger-11370
```
## Current Features
- Collab
- Breakpoints
- Sync when you (re)join a project
- Sync when you add/remove a breakpoint
- Sync active debug line
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Restart stack frame (if adapter supports this)
- Variables
- Loaded sources
- Modules
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Debug console
- Breakpoints
- Log breakpoints
- line breakpoints
- Persistent between zed sessions (configurable)
- Multi buffer support
- Toggle disable/enable all breakpoints
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Show collapsed stack frames
- Restart stack frame (if adapter supports this)
- Loaded sources
- View all used loaded sources if supported by adapter.
- Modules
- View all used modules (if adapter supports this)
- Variables
- Copy value
- Copy name
- Copy memory reference
- Set value (if adapter supports this)
- keyboard navigation
- Debug Console
- See logs
- View output that was sent from debug adapter
- Output grouping
- Evaluate code
- Updates the variable list
- Auto completion
- If not supported by adapter, we will show auto-completion for existing
variables
- Debug Terminal
- Run custom commands and change env values right inside your Zed
terminal
- Attach to process (if adapter supports this)
- Process picker
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Disconnect
- Restart
- Stop
- Warning when a debug session exited without hitting any breakpoint
- Debug view to see Adapter/RPC log messages
- Testing
- Fake debug adapter
- Fake requests & events
---
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Piotr <piotr@zed.dev>
This PR adds new columns to the `extension_versions` table to record
which features an extension provides.
These `provides_*` columns are populated from the `provides` field on
the extension manifest.
We'll be able to leverage this data in the future for showing what an
extension provides in the extensions UI, as well as allowing to filter
by extensions that provide a certain feature.
Release Notes:
- N/A
This PR adds a new `has_overdue_invoices` field to the
`billing_customers` table.
This will be used to statefully track whether a customer has overdue
invoices, and also to reset it when the invoices are paid.
We will set this field to `true` when a subscription is canceled with
the reason `payment_failed`.
Release Notes:
- N/A
https://github.com/user-attachments/assets/78db908e-cfe5-4803-b0dc-4f33bc457840
* starts to extract usernames out of `users/` GitHub API responses, and
pass those along with e-mails in the collab sessions as part of the
`User` data
* adjusts various prefill and seed test methods so that the new data can
be retrieved from GitHub properly
* if there's an active call, where guests have write permissions and
e-mails, allow to trigger `FillCoAuthors` action in the context of the
git panel, that will fill in `co-authored-by:` lines, using e-mail and
names (or GitHub handle names if name is absent)
* the action tries to not duplicate such entries, if any are present
already, and adds those below the rest of the commit input's text
Concerns:
* users with write permissions and no e-mails will be silently omitted
— adding odd entries that try to indicate this or raising pop-ups is
very intrusive (maybe, we can add `#`-prefixed comments?), logging seems
pointless
* it's not clear whether the data prefill will run properly on the
existing users — seems tolerable now, as it seems that we get e-mails
properly already, so we'll see GitHub handles instead of names in the
worst case. This can be prefilled better later.
* e-mails and names for a particular project may be not what the user
wants.
E.g. my `.gitconfig` has
```
[user]
email = mail4score@gmail.com
# .....snip
[includeif "gitdir:**/work/zed/**/.git"]
path = ~/.gitconfig.work
```
and that one has
```
[user]
email = kirill@zed.dev
```
while my GitHub profile is configured so, that `mail4score@gmail.com` is
the public, commit e-mail.
So, when I'm a participant in a Zed session, wrong e-mail will be
picked.
The problem is, it's impossible for a host to get remote's collaborator
git metadata for a particular project, as that might not even exist on
disk for the client.
Seems that we might want to add some "project git URL <-> user name and
email" mapping in the settings(?).
The design of this is not very clear, so the PR concentrates on the
basics for now.
When https://github.com/zed-industries/zed/pull/23308 lands, most of the
issues can be solved by collaborators manually, before committing.
Release Notes:
- N/A
First, parse the output of `git status --porcelain=v1` into a
representation that can handle the full "grammar" and doesn't lose
information.
Second, as part of pushing this throughout the codebase, expand the use
of the existing `GitSummary` type to all the places where status
propagation is in play (i.e., anywhere we're dealing with a mix of files
and directories), and get rid of the previous `GitSummary ->
GitFileStatus` conversion.
- [x] Synchronize new representation over collab
- [x] Update zed.proto
- [x] Update DB models
- [x] Update `GitSummary` and summarization for the new `FileStatus`
- [x] Fix all tests
- [x] worktree
- [x] collab
- [x] Clean up `FILE_*` constants
- [x] New collab tests to exercise syncing of complex statuses
- [x] Run it locally and make sure it looks good
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
This PR updates the `billing_subscriptions` in the database to record
the cancellation reason from Stripe.
We're primarily interested in this so we can check for subscriptions
that were canceled for being `past_due`.
Release Notes:
- N/A
This PR adds a new `billing_preferences` table.
Right now there is a single preference: the maximum monthly spend for
LLM usage.
Release Notes:
- N/A
---------
Co-authored-by: Richard <richard@zed.dev>
This PR does not change how things work for settings, but lays the
ground work for the future functionality.
After this change, Zed is prepared to sync more than just
`settings.json` files from local worktree and user config.
* ssh tasks
Part of this work is to streamline the task sync mechanism.
Instead of having an extra set of requests to fetch the task contents
from the server (as remote-via-collab does now and does not cover all
sync cases), we want to reuse the existing mechanism for synchronizing
user and local settings.
* editorconfig
Part of the task is to sync .editorconfig file changes to everyone which
involves sending and storing those configs.
Both ssh (and remove-over-collab) .zed/tasks.json and .editorconfig
files behave similar to .zed/settings.json local files: they belong to a
certain path in a certain worktree; may update over time, changing Zed's
functionality; can be merged hierarchically.
Settings sync follows the same "config file changed -> send to watchers
-> parse and merge locally and on watchers" path that's needed for both
new kinds of files, ergo the messaging layer is extended to send more
types of settings for future watch & parse and merge impls to follow.
Release Notes:
- N/A
Release Notes:
- Fixed the issue related to the project wide search being stuck when
project contains .fifo files
- Might potentially solve the following issue
https://github.com/zed-industries/zed/issues/7360
This PR makes the `github_user_id` column on the `users` table required
and replaces the index with a unique index.
I have gone through and ensured that all users have a unique
`github_user_id` in the staging and production databases.
Release Notes:
- N/A
This PR restricts usage of the LLM service to accounts older than 30
days.
We now store the GitHub user's `created_at` timestamp to check the
GitHub account age. If this is not set—which it won't be for existing
users—then we use the `created_at` timestamp in the Zed database.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
This adds the requirement for users to accept the terms of service the
first time they send a message with the Cloud provider.
Once this is out and in a nightly, we need to add the check to the
server side too, to authenticate access to the models.
Demo:
https://github.com/user-attachments/assets/0edebf74-8120-4fa2-b801-bb76f04e8a17
Release Notes:
- N/A
This PR reworks how we process Stripe events for reconciliation
purposes.
The previous approach in #15480 turns out to not be workable, on account
of the Stripe event IDs not being strictly in order. This meant that we
couldn't reliably compare two arbitrary event IDs and determine which
one was more recent.
This new approach leans on the guidance that Stripe provides for
webhooks events:
> Webhook endpoints might occasionally receive the same event more than
once. You can guard against duplicated event receipts by logging the
[event IDs](https://docs.stripe.com/api/events/object#event_object-id)
you’ve processed, and then not processing already-logged events.
>
> https://docs.stripe.com/webhooks#handle-duplicate-events
We now record processed Stripe events in the `processed_stripe_events`
table and use this to filter out events that have already been
processed, so we do not process them again.
When retrieving events from the Stripe events API we now buffer the
unprocessed events so that we can sort them by their `created` timestamp
and process them in (roughly) the order they occurred.
Release Notes:
- N/A
This PR improves our Stripe event handling by keeping track of the last
event we've seen for each record.
The `billing_customers` and `billing_subscriptions` tables both have a
new `last_stripe_event_id` column. When we apply an event to one of
these records, we store the event ID that was applied.
Then, when we are going through events we can ignore any event that has
an ID that came before the `last_stripe_event_id` (based on the
lexicographical ordering of the IDs).
Release Notes:
- N/A
This PR adds a new `billing_customers` table to hold the billing
customers.
Previously we were storing both the `stripe_customer_id` and
`stripe_subscription_id` in the `billable_subscriptions` table. However,
this creates problems when we need to correlate subscription events back
to the subscription record, as we don't know the user that the Stripe
event corresponds to.
By moving the `stripe_customer_id` to a separate table we can create the
Stripe customer earlier in the flow—before we create the Stripe Checkout
session—and associate that customer with a user. This way when we
receive events down the line we can use the Stripe customer ID to
correlate it back to the user.
We're doing some destructive actions to the `billing_subscriptions`
table, but this is fine, as we haven't started using them yet.
Release Notes:
- N/A
This PR adds a new `billing_subscriptions` table to the database, as
well as some accompanying models/queries.
In this table we store a minimal amount of data from Stripe:
- The Stripe customer ID
- The Stripe subscription ID
- The status of the Stripe subscription
This should be enough for interactions with the Stripe API (e.g., to
[create a customer portal
session](https://docs.stripe.com/api/customer_portal/sessions/create)),
as well as determine whether a subscription is active (based on the
`status`).
Release Notes:
- N/A
Co-Authored-By: Mikayla <mikayla@zed.dev>
In a fit of ill-advisedness I called these things remote projects;
forgetting that remote project is also what we call collaboratively
shared projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
Release Notes:
- Made remote projects per-user instead of per-channel. If you'd like to
be part of the remote development alpha, please email hi@zed.dev.
---------
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Nate Butler <1714999+iamnbutler@users.noreply.github.com>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
This introduces semantic indexing in Zed based on chunking text from
files in the developer's workspace and creating vector embeddings using
an embedding model. As part of this, we've created an embeddings
provider trait that allows us to work with OpenAI, a local Ollama model,
or a Zed hosted embedding.
The semantic index is built by breaking down text for known
(programming) languages into manageable chunks that are smaller than the
max token size. Each chunk is then fed to a language model to create a
high dimensional vector which is then normalized to a unit vector to
allow fast comparison with other vectors with a simple dot product.
Alongside the vector, we store the path of the file and the range within
the document where the vector was sourced from.
Zed will soon grok contextual similarity across different text snippets,
allowing for natural language search beyond keyword matching. This is
being put together both for human-based search as well as providing
results to Large Language Models to allow them to refine how they help
developers.
Remaining todo:
* [x] Change `provider` to `model` within the zed hosted embeddings
database (as its currently a combo of the provider and the model in one
name)
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Antonio <antonio@zed.dev>
* Store extensions versions' wasm API version in the database
* Share a common struct for extension API responses between collab and
client
* Add wasm API version and schema version to extension API responses
Release Notes:
- N/A
Co-authored-by: Marshall <marshall@zed.dev>
This PR provides some of the plumbing needed for a "remote" zed
instance.
The way this will work is:
* From zed on your laptop you'll be able to manage a set of dev servers,
each of which is identified by a token.
* You'll run `zed --dev-server-token XXXX` to boot a remotable dev
server.
* From the zed on your laptop you'll be able to open directories and
work on the projects on the remote server (exactly like collaboration
works today).
For now all this PR does is provide the ability for a zed instance to
sign in
using a "dev server token". The next steps will be:
* Adding support to the collaboration protocol to instruct a dev server
to "open" a directory and share it into a channel.
* Adding UI to manage these servers and tokens (manually for now)
Related #5347
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
