fix: deleting a document will always discard all versions of the document too

[jordanl17]

Description

We are currently only using the document.delete action when a published document exists. document.delete requires a published ID that exists. There are a couple of issues

1. We are not passing includedDrafts array through to document.delete which means that we are not also deleting the other versions of the document that exist
2. When a published document doesn't exist, we are using document.discard which is firstly a deprecated action, and secondly only discard a single document version, rather than all versions.

This PR makes the changes so that:

1. includedDrafts passes the document Ids of all versions to delete the published and all other versions of the document
2. version.discard is used instead of document.discard and the actions are chained together to delete all the versions of that document

Before:
Release version document is not deleted

After:
All versions of the document are deleted

What to review

Testing

Notes for release

Fixes an issue where deleting a document would in some cases not delete all versions of that document.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
page-building-studio	Ready	Preview	Comment	Nov 28, 2025 1:28pm
test-studio	Ready	Preview	Comment	Nov 28, 2025 1:28pm

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
e2e-studio	Ignored			Nov 28, 2025 1:28pm
studio-workshop	Ignored			Nov 28, 2025 1:28pm
test-next-studio	Ignored			Nov 28, 2025 1:28pm

[github-actions]

🧪 E2E Preview environment

🔑 Environment Variables for Local Testing

This is the preview URL for the E2E tests: https://e2e-studio-qeehoesly.sanity.dev

To run the E2E tests locally, you can use the following environment variables, then run pnpm test:e2e --ui to open the Playwright test runner.

💬 Remember to build the project first with pnpm build:e2e.

  SANITY_E2E_PROJECT_ID=ittbm412
  SANITY_E2E_BASE_URL=https://e2e-studio-qeehoesly.sanity.dev
  SANITY_E2E_DATASET="update depending the project you want to test (pr-11336-chromium-19765155601 || pr-11336-firefox-19765155601 )"
  SANITY_E2E_DATASET_CHROMIUM=pr-11336-chromium-19765155601
  SANITY_E2E_DATASET_FIREFOX=pr-11336-firefox-19765155601

[github-actions]

🧪 E2E Preview environment

Waiting for preview deployment to finish…

[github-actions]

📊 Playwright Test Report

Download Full E2E Report

This report contains test results, including videos of failing tests.

[github-actions]

📊 Playwright Test Report

Waiting for E2E tests to finish…

[github-actions]

⚡️ Editor Performance Report

Updated Fri, 28 Nov 2025 13:59:11 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	30.3 efps (33ms)	26.3 efps (38ms)	+5ms (+15.2%)	✅
article (body)	36.3 efps (28ms)	37.6 efps (27ms)	-1ms (-3.4%)	✅
article (string inside object)	28.6 efps (35ms)	27.8 efps (36ms)	+1ms (+2.9%)	✅
article (string inside array)	25.6 efps (39ms)	23.5 efps (43ms)	+4ms (+9.0%)	✅
recipe (name)	43.5 efps (23ms)	50.0 efps (20ms)	-3ms (-13.0%)	✅
recipe (description)	64.5 efps (16ms)	62.5 efps (16ms)	+1ms (+3.2%)	✅
recipe (instructions)	99.9+ efps (7ms)	99.9+ efps (6ms)	-1ms (-/-%)	✅
singleString (stringField)	55.6 efps (18ms)	66.7 efps (15ms)	-3ms (-16.7%)	✅
synthetic (title)	16.7 efps (60ms)	16.5 efps (61ms)	+1ms (+0.8%)	✅
synthetic (string inside object)	17.2 efps (58ms)	17.2 efps (58ms)	+0ms (-/-%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	33ms	36ms	40ms	53ms	38ms	8.7s
article (body)	28ms	30ms	67ms	117ms	150ms	6.2s
article (string inside object)	35ms	40ms	57ms	100ms	0ms	5.9s
article (string inside array)	39ms	44ms	56ms	139ms	111ms	6.3s
recipe (name)	23ms	27ms	36ms	69ms	0ms	6.6s
recipe (description)	16ms	18ms	22ms	32ms	0ms	4.2s
recipe (instructions)	7ms	10ms	12ms	18ms	0ms	3.0s
singleString (stringField)	18ms	20ms	21ms	43ms	0ms	5.9s
synthetic (title)	60ms	63ms	115ms	167ms	422ms	14.9s
synthetic (string inside object)	58ms	60ms	65ms	146ms	251ms	7.6s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	38ms	42ms	48ms	100ms	20ms	9.3s
article (body)	27ms	30ms	68ms	113ms	117ms	6.1s
article (string inside object)	36ms	38ms	42ms	67ms	0ms	5.7s
article (string inside array)	43ms	47ms	62ms	99ms	3ms	6.4s
recipe (name)	20ms	25ms	36ms	47ms	0ms	6.8s
recipe (description)	16ms	19ms	20ms	39ms	0ms	4.1s
recipe (instructions)	6ms	10ms	11ms	15ms	0ms	3.0s
singleString (stringField)	15ms	17ms	23ms	39ms	0ms	5.7s
synthetic (title)	61ms	64ms	71ms	112ms	454ms	15.0s
synthetic (string inside object)	58ms	63ms	115ms	144ms	196ms	8.0s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	44.45%	63912 / 143759
🔵	Statements	44.45%	63912 / 143759
🔵	Functions	48.32%	3411 / 7059
🔵	Branches	79.33%	12976 / 16356

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/store/_legacy/document/document-pair/serverOperations/delete.ts	18%	50%	50%	18%	12-55

Generated in workflow #46690 for commit 067049a by the Vitest Coverage Report Action