Draft document auto-restores after deletion in Sanity Studio

This is a tricky issue, and the fact that it happens consistently with one document type but not another is the key diagnostic clue. Since CLI deletion works fine, this points to something in your Studio configuration rather than a Content Lake issue.

Here are the most likely causes and how to debug them:

Compare the Two Document Types Side-by-Side

Since you have one document type that works correctly and one that doesn't, do a detailed diff of their schema definitions. Look specifically at:

• Reference fields: Fields that reference other documents, especially if they have custom preview components
• Custom input components: Any field using a custom React component
• Validation rules: Complex validation that might maintain document state
• Preview configurations: Custom preview selectors or components
• Field-level configurations: Hidden fields, read-only fields, or conditional field logic

Check Your Structure/Desk Configuration

If you have a custom structure configuration (in sanity.config.ts or a separate structure file), look for anything specific to the problematic document type:

• Custom list views or filters
• Document list preview configurations
• Any structure items that specifically query or reference that document type

Inspect Network Traffic During Deletion

This is your best diagnostic tool. Open browser DevTools → Network tab, then delete the draft. Watch for:

1. The DELETE mutation (should succeed)
2. Any subsequent CREATE or PATCH mutations that happen immediately after
3. The payload of those follow-up mutations will tell you exactly what's recreating the document

Filter the network requests to just show calls to api.sanity.io to reduce noise.

Check for Document-Level Subscriptions

Look through your codebase for anything that might be subscribing to or maintaining a reference to documents of that type:

• Custom Studio plugins
• Form components that use useFormValue or useDocumentStore
• Any real-time listeners or observers

Known Studio Quirks

There have been reports of Studio's presence system (which tracks who's editing what) sometimes causing unexpected behavior with drafts, though this is rare. The fact that the restored document has the same ID as the original is expected (drafts use drafts.{id} as their document ID), but the restoration itself is not normal behavior.

Recommended Next Steps

1. Isolate the difference: Create a minimal version of the working document type, then gradually add fields/config from the problematic type until you reproduce the issue
2. Check Studio version: Make sure you're on the latest Studio v3 (or v4) version, as some draft-handling bugs have been fixed in recent releases
3. Report with reproduction: If you can create a minimal reproduction case, report this to Sanity support - this could be a Studio bug that needs fixing

The network inspection is really your best bet here - it will show you exactly what operation is recreating the document and that will point you to the source of the problem in your configuration.

Have you noticed if the "restored" document appears immediately after deletion, or does it take a few seconds? That timing might also provide clues about whether it's a synchronous operation in your Studio code vs. something async.