Delete a shared haul link, and know what is actually gone

Delete means gone, and gone has to mean now

A shared haul is a public address. You paste it into a thread, the thread runs its course, and then you want the address to stop working. That is the ordinary case, and it is the one worth getting right, because the reason people hesitate to share a haul at all is that they cannot see how to un-share it.

So the promise is short. Open Profile, then Shared links, press Delete on the row, and the page answers 404 straight away. Not in an hour. Not once something expires. Straight away, on the next request, from anywhere.

Keeping that promise takes more work than it sounds like, and the rest of this page explains why — because the difference between a delete that works and a delete that looks like it works is invisible from the outside until somebody catches it.

The row is not what a reader gets

A shared haul page is not a file sitting on a disk. It is built when somebody asks for it: a request arrives, we read one row out of the database, and we render the page from that row. Delete the row and there is nothing left to render, so the next request gets a 404. That much is easy.

The complication is that we do not rebuild the page for every reader. A haul posted to a busy thread might be opened two hundred times in an hour, and rebuilding it two hundred times is two hundred database reads for two hundred identical answers. So the page is cached at the edge — held on the servers closest to each reader — and served from there without touching us at all. The photo that a chat draws in its preview card is cached the same way, and held far longer, because a photo does not change.

Now the problem is visible. Deleting the row changes what we would build. It does not change what is already built and sitting at the edge. A cache does not know a database exists. Unless something tells it otherwise, it keeps serving the answer it last received until the age we stamped on that answer runs out.

Read the second row again. A delete that stops at the database is a delete that leaves the photo of your haul on the open web for a week. The page would go quiet in an hour and the picture would outlast it by six days, which is the worst possible shape for this to fail in: you check the address, you see the 404, you believe it worked.

Every cached answer carries a handle

The fix is to label things. Every page and every photo we send for a shared haul goes out with a tag naming that haul's address. The tag is for the cache, not for the reader — it is stripped before the response reaches a browser, so nobody sees it and nothing downstream stores it.

When you delete the link, two things happen in order. First the row goes. Then we call the cache and name the tag, and every copy of that page and that photo, on every edge server holding one, is dropped. The order matters: purging first would leave a gap in which one more request rebuilds the page from a row that is about to disappear, and re-caches it on the way out.

If the cache call fails — a network blip, a rate limit — your delete still succeeds. The row is already gone, and the page will age out on its own within the hour. Failing your delete because a cache was busy would be the worse outcome, so we record the failure for ourselves and tell you the link is deleted, which it is.

Deleting your whole account does the same thing, once, for every link you ever published. That is the stronger version of the same promise. One tidied-up thread is housekeeping; an account deletion is somebody asking us to take their things off the open web, and leaving a card photo behind for a week would not be an answer to that.

What a delete cannot reach

Some things are outside our reach, and a guide that does not say so is not much of a guide. Here is the full division.

Rows four and five are the ones to plan around. A chat client fetches a page the moment an address appears in the box and keeps the card it drew in its own storage. Deleting the source does not reach into Discord's servers and rub out a card from last Tuesday. If the card is what you want gone, delete the message that carries it.

If a card is a problem often enough to matter, the better move is to stop it being drawn in the first place. Read what an unlisted link hides — it blanks the card at the moment of pasting, so there is nothing for a chat to keep.

Deleting is also how you get a slot back

A free account keeps 3 links at a time. Pro keeps 100. The count is of links standing right now, not of links you have ever made, so a delete returns a slot the moment it goes through and the next share works immediately.

If you share often, the habit worth building is to delete when the thread dies rather than when you hit the cap. Reaching the cap and then hunting for something to remove is a worse minute than removing it when you were already finished with it. Set an expiry at the moment you create the link, and the removal happens on its own — see share a haul list without sharing your whole shelf for how the fields and the expiry are chosen.

Nothing about deleting touches the haul it came from. The shared page was a snapshot taken when you pressed Share, never a live window onto your shelf, and the shelf carries on exactly as it was. That is also why editing an item after sharing does not change the shared page — the two stopped being connected at the moment the link was made.

Straight answers

I deleted it and I still see the haul. You are almost certainly reading your own browser's copy, because you opened that address before. Reload without the cache, or open the address in a private window. If a different device on a different network still shows it, tell us the address and we will look.

Can I put the same address back? No. Addresses are drawn at random and never reissued, so a deleted one stays dead. Sharing the haul again makes a new address, and the old one keeps answering 404 forever.

Does deleting my account do this too? Yes, for every link at once, in the same step that removes your data.

Where do I start? Open Credenza, build a haul, and share it when you want an opinion on it. Knowing you can take it back is the point of reading this before you post, not after.