Get help on Discord

Draft document deleted via CLI still showing in desk tool's main document list

10 replies
Last updated: Jun 16, 2023
I have a draft document that was created via the Sanity client like this:
transaction
    .createIfNotExists(document)
    .patch(draftId, patch => patch.set(document));
It was then deleted via the CLI but is still showing up in the desk tool's main document list for the doc type. The CLI and Vision both confirm the document does not exist, yet is still showing. This is happening on 
v2.34
. Any ideas on how to resolve this?
AI Update

This is a known caching issue in older versions of Sanity Studio where the desk tool's document list can get out of sync with the actual Content Lake data. Since you've confirmed via CLI and Vision that the document doesn't exist, this is purely a frontend/cache issue in Studio.

Here are several approaches to resolve this, in order of what to try first:

1. Hard refresh the browser Try a hard refresh (Ctrl+Shift+R or Cmd+Shift+R) to clear the browser cache. The desk tool maintains some client-side caching that can become stale.

2. Clear browser local storage Open your browser's developer tools, go to Application/Storage → Local Storage, and clear the storage for your Studio domain. This will force the desk tool to rebuild its cache from scratch.

3. Restart the Studio dev server If you're running sanity dev, stop and restart it. Sometimes the Studio's internal state can get cached during development.

4. Check for phantom published version Even though you deleted the draft, there might be a published version still lingering. Try explicitly deleting both versions via the CLI:

sanity documents delete drafts.YOUR_DOCUMENT_ID
sanity documents delete YOUR_DOCUMENT_ID

5. Upgrade Studio (most important) You're running v2.34, which is quite old. Many caching and sync issues were fixed in later versions. Studio v3 (and now v4) have significantly improved document list handling and real-time synchronization. Consider migrating to Studio v3 or at least upgrading to the latest v2 version if immediate migration isn't feasible.

Why this happens: In older Studio versions, the desk tool's document list uses a combination of real-time listeners and cached queries. When documents are deleted outside of Studio (via CLI or client), the real-time listeners sometimes don't properly invalidate the cached list, leaving "ghost" entries visible.

If none of these work, try clicking on the ghost document in the list - it should fail to load and might trigger a cache invalidation that removes it from the list.

Hi
user A
. It’s possible that the draft (with an 
_id
of 
drafts.document
) still exists.
Thanks for the reply
user A
. How can I delete it? Also why is the document with 
drafts.
path showing in the main list, and in the browser URL? I haven't seen that behaviour before.
Actually, I missed your mention of it being a draft in your initial post. I’m not entirely sure I’m following your process. Please let me know if I have this right:
1. You created a draft document in the client that had an 
_id
of 
drafts.451f5de0-b1fc-4a2d-a92d-f58f9f84c160
.2. You opened that document in the Studio, and the 
drafts.
prefix was in the URL.3. You deleted the document via the CLI with the command 
sanity documents delete "drafts.451f5de0-b1fc-4a2d-a92d-f58f9f84c160"
.4. The document remains in the Studio’s document list, even though 
drafts.451f5de0-b1fc-4a2d-a92d-f58f9f84c160
returns no results in Vision nor the CLI.If you open the document in the Studio and inspect the JSON, what’s the 
_id
?
yes that process is correct. for one document, the URL shows the drafts path, but inspecting the JSON shows the published _id:
For the other document, the URL shows the drafts path, but the JSON shows no _id field at all. there is also no title field, even though the title is showing in the document list.
What shows in the URL bar for the other document?
URL: 
drafts.c8a12195-35c7-4217-9475-33bb697fa73a
JSON:
user A
I think I figured out what was happening. The ID being used to patch the draft document could either be the published document's ID, or the draft ID. In the case where it was the draft ID, a new document with the ID of 
drafts.drafts.c8a12195-35c7-4217-9475-33bb697fa73a
was actually created. This is why it was showing in the main list - what's weird is that the JSON inspect didn't show that as the ID. I was able to use the CLI to delete that double 
drafts
version of the document, and update the transaction code so that doesn't happen now.
Wild! I’ve never come across that happening before, but I guess 
drafts.drafts.ID
still fits the Studio’s expectation of a draft 
_id
. Thanks for updating to let me know, and I’m glad you got it worked out!

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?