Unpublishing drops unsaved edits, and the next save after an unpublish or a discard is refused as a conflict

[danielmlr]

Description

After unpublishing a post or discarding its draft, the editor's next save is refused as a conflict with that same action. Unpublishing also throws away whatever autosave had not sent yet.

Both actions bump the entry's version and the server returns the new _rev, but the admin does not read it. Since #2860 the editor no longer takes its token from the reloaded entry: it reads it once when it opens the entry and then updates it from its own saves, publishes and schedules. So the next save goes out with the old token, gets a 409, and the editor shows "This entry changed somewhere else after you opened it." Publish saves first, so clicking Publish right after an unpublish fails the same way and the post stays unpublished. That is how a writer would undo the misclick #2517 describes. Restoring a revision from the sidebar returns a new _rev that is not read either, so it leaves the same stale token.

Unpublishing also reloads the entry without saving first, so the reloaded copy replaces the unsent edits and the header reads "Saved". It is the reset #2965 reported for the publication date, which publish, schedule and the date control avoid by saving pending changes before they write.

Reading the new token from these responses, and saving pending changes before unpublishing, closes both. I have tests and a fix for unpublish and discard.

I think this belongs under the "manual save, autosave, and publish do not race" criterion in #1683. Its scope lists unpublish and discard, and the editor's save-ordering tests do not cover them.

Steps to reproduce

1. In a collection that supports drafts and revisions, open a published post that has no pending changes.
2. Click "Unpublish Post".
3. Type one character into the title and wait two seconds for autosave.
4. The autosave request gets a 409 and the banner appears.

The same happens after "Discard changes" on a post with draft changes, and after restoring an older revision from the Revisions panel. Clicking "Publish now" right after step 2 fails the same way, and the post stays unpublished.

For the lost edits: open a published post, type into the title, and click "Unpublish Post" within two seconds. The typed text disappears, the header reads "Saved", and no save request is sent.

Environment

• emdash version: 0.37.0, and the same on main at b581ff8
• Node.js version: 26.8.1
• Runtime: Node (@astrojs/node, astro dev)
• OS: macOS

Screenshots

Logs / error output

# Requests after unpublishing and typing one character; _rev decoded from base64
POST /_emdash/api/content/posts/<id>/unpublish  200  sent: no body         returned _rev 7:2026-09-12T22:03:51.140Z
GET  /_emdash/api/content/posts/<id>            200                         returned _rev 7:2026-09-12T22:03:51.140Z
PUT  /_emdash/api/content/posts/<id>            409  sent _rev 6:2026-09-12T22:03:33.890Z
     "Content has been modified since last read (version conflict)"

[emdashbot]

Completed

Unpublishing drops unsaved edits, and the next save after an unpublish or a discard is refused as a conflict

• Review the issue and relevant repository context

Outcome: **Confirmed bug: admin editor drops the new `_rev` token from unpublish/discard/revision-restore responses and unpublish does not flush pending edits first.**

Evidence from `packages/admin/src/lib/api/content.ts`:

• `unpublishContent()` and `discardDraft()` parse the response as `{ item: ContentItem }` only, discarding the `_rev` the server returns.
• `restoreRevision()` does the same.
• In `packages/admin/src/router.tsx`, the `unpublishMutation` and `discardDraftMutation` `onSuccess` callbacks never update `revisionTokensRef.current`, so the editor keeps the pre-action `_rev` and the next save/autosave sends a stale token, producing the 409 shown in the report.
• `handleUnpublish` is just `() => unpublishMutation.mutate()` — unlike `handlePublish`/`handleSchedule`, it does not call `serializeEditorSave` first, so unsaved editor changes are overwritten by the refetched entry after the mutation succeeds.

The server routes already return the new token (e.g., `handleContentUnpublish` returns `{ item, _rev: encodeRev(item) }`), and the content schemas accept an optional `_rev`, so the fix is localized to the admin client:

1. Update `unpublishContent`/`discardDraft` to accept/pass `_rev` and return the new token; do the same for `handleRevisionRestore` in `packages/core/src/api/handlers/revision.ts` (it currently returns only `item`).
2. In `router.tsx`, make `handleUnpublish` save pending changes first and then unpublish with the saved `_rev`; update all three mutations to write the returned `_rev` into `revisionTokensRef.current`.
3. Update `RevisionHistory.tsx` to accept and use the restored `_rev`.
4. Add tests covering save ordering for unpublish/discard and the revision-restore token update, similar to `packages/admin/tests/publish-autosave-race.test.tsx`.

Mode: triage

View live dashboard · Run: 496c3fa8-1a6d-4d02-9ef5-9900202ae311

[emdashbot]

Completed

Published candidate branch with bug fix, tests, and changeset.

• Reproduce: Understand current code & write failing tests
• Diagnose: identify where _rev tokens are dropped
• Fix: preserve _rev tokens and flush pending edits before unpublish
• Verify: run focused tests, typecheck, lint, format
• Publish candidate and report results

Outcome: Fixed issue #3089: the admin editor now keeps its revision token up-to-date after unpublish, discard-draft, and revision-restore actions, and unpublish flushes pending editor edits first.

Changes:

• `packages/admin/src/lib/api/content.ts`: `unpublishContent`, `discardDraft`, and `restoreRevision` now parse and return `_rev`.
• `packages/core/src/api/handlers/revision.ts`: `handleRevisionRestore` returns `_rev: encodeRev(item)` alongside the restored `item`.
• `packages/admin/src/router.tsx`: `handleUnpublish` saves pending changes before unpublishing; unpublish, discard, and restore mutations update `revisionTokensRef.current` with the returned `_rev`.
• `packages/admin/src/components/ContentEditor.tsx` & `ContentSettingsPanel.tsx`: pass revision-restore callbacks so the editor token can be updated.
• `packages/admin/src/components/RevisionHistory.tsx`: consumes restored `_rev`.
• Added tests: `packages/admin/tests/unpublish-discard-revision-token.test.tsx` (unpublish flush + token advance, publish-after-unpublish, discard token update) and `packages/admin/tests/lib/api/content-token.test.ts` (API token parsing).
• Added changeset `.changeset/unpublish-token-fix.md` for `@emdash-cms/admin` and `emdash` patch releases.

Verification:

• `pnpm build` at repo root: passed
• `pnpm typecheck` in `packages/admin` and `packages/core`: passed
• `pnpm lint:json` in repo root: 0 diagnostics
• `pnpm format`: passed
• Admin focused tests: 25 passed (publish-autosave-race suite, new unpublish/discard/revision-token suite, and content-token unit tests)
• Core focused tests: `revision-handlers.test.ts` (11 passed), `publish-revision-cas.test.ts` (9 passed)

Mode: work

View live dashboard · Run: 96dff0fe-8c0a-4951-861b-6b0042579d3c

[emdashbot]

A candidate change is ready to preview.

Fixed issue #3089: the admin editor now keeps its revision token up-to-date after unpublish, discard-draft, and revision-restore actions, and unpublish flushes pending editor edits first.

Changes:

• packages/admin/src/lib/api/content.ts: unpublishContent, discardDraft, and restoreRevision now parse and return _rev.
• packages/core/src/api/handlers/revision.ts: handleRevisionRestore returns _rev: encodeRev(item) alongside the restored item.
• packages/admin/src/router.tsx: handleUnpublish saves pending changes before unpublishing; unpublish, discard, and restore mutations update revisionTokensRef.current with the returned _rev.
• packages/admin/src/components/ContentEditor.tsx & ContentSettingsPanel.tsx: pass revision-restore callbacks so the editor token can be updated.
• packages/admin/src/components/RevisionHistory.tsx: consumes restored _rev.
• Added tests: packages/admin/tests/unpublish-discard-revision-token.test.tsx (unpublish flush + token advance, publish-after-unpublish, discard token update) and packages/admin/tests/lib/api/content-token.test.ts (API token parsing).
• Added changeset .changeset/unpublish-token-fix.md for @emdash-cms/admin and emdash patch releases.

Verification:

• pnpm build at repo root: passed
• pnpm typecheck in packages/admin and packages/core: passed
• pnpm lint:json in repo root: 0 diagnostics
• pnpm format: passed
• Admin focused tests: 25 passed (publish-autosave-race suite, new unpublish/discard/revision-token suite, and content-token unit tests)
• Core focused tests: revision-handlers.test.ts (11 passed), publish-revision-cas.test.ts (9 passed)

Try the change against your own site:

npm i https://pkg.pr.new/emdash@bot/fix-3089

Or try the candidate in a ready-to-use playground:

Open the playground preview

@danielmlr could you try this? Reply naturally to say whether it works or explain what still needs to change.

_{A maintainer can accept on the reporter's behalf. Acceptance opens a draft PR; requested changes start another candidate revision.}

Fix branch: bot/fix-3089 · Artifacts branch: bot/artifacts-3089

[danielmlr]

I tried emdash@bot/fix-3089 from pkg.pr.new on a copy of the Node site from the report. The paths in the report work now, and one thing still needs to change in unpublish. An unsent title edit is saved before the unpublish and stays in the field, Publish right after Unpublish goes through, and typing after an unpublish, a discard or a restore autosaves without the banner. Restore followed by Publish works too.

# Requests on the preview, _rev version decoded from base64
PUT   /content/posts/<id>                200  sent 27, returned 28   unsent edit, saved first
POST  /content/posts/<id>/unpublish      200  sent 28, returned 29
PUT   /content/posts/<id>                200  sent 29                autosave after unpublish
POST  /content/posts/<id>/discard-draft  200  returned 34
PUT   /content/posts/<id>                200  sent 34                autosave after discard
POST  /revisions/<id>/restore            200  returned 36
PUT   /content/posts/<id>                200  sent 36                autosave after restore

When the editor refuses an unpublish, nothing catches the rejection: double-clicking "Unpublish Post" unpublishes once and then throws an unhandled rejection (A publishing action is already in progress), and a single click while a URL field is invalid throws one too (Fix invalid fields before changing the schedule). handleUnpublish in ContentEditor.tsx returns the runScheduleChange promise straight to the button's onClick, while "Remove schedule" wraps its call in .catch(() => undefined). Unpublish needs the same.