zed-industries/zed · error
Auto-close Operation Failed - Buffer has edits since start
Error message
Auto-close Operation Failed - Buffer has edits since start
What it means
The JSX tag auto-close edit was aborted because the buffer received edits after the operation's start snapshot was taken. The ensure_no_edits_since_start guard (has_edits_since on the start version) detected concurrent modification, so applying the closing tag now would corrupt the buffer; the whole auto-close operation fails deliberately.
Source
Thrown at crates/editor/src/jsx_tag_auto_close.rs:462
let buffer_snapshot = buffer.read_with(cx, |buf, _| buf.snapshot());
let Some(edit_behavior_state) =
should_auto_close(&buffer_snapshot, &edited_ranges, &jsx_tag_auto_close_config)
else {
return Some(());
};
let ensure_no_edits_since_start = || -> Option<()> {
let has_edits_since_start = this
.read_with(cx, |this, cx| {
this.buffer.read(cx).buffer(buffer_id).is_none_or(|buffer| {
buffer.read(cx).has_edits_since(&buffer_version_initial)
})
})
.ok()?;
if has_edits_since_start {
Err(anyhow!(
"Auto-close Operation Failed - Buffer has edits since start"
))
.log_err()?;
}
Some(())
};
ensure_no_edits_since_start()?;
let edits = cx
.background_executor()
.spawn({
let buffer_snapshot = buffer_snapshot.clone();
async move {
generate_auto_close_edits(
&buffer_snapshot,
&edited_ranges,View on GitHub (pinned to f4178619ac)
Solutions
- Drop the auto-close operation entirely — the user's newer edit takes precedence
- Re-run should_auto_close against the current snapshot instead of the stale one if the edit is still applicable
- Ensure the start version is captured as late as possible to shrink the race window
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at crates/editor/src/jsx_tag_auto_close.rs:462 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20).
Data as JSON: /api/errors/3918a61445eae420.
Report an issue: GitHub.