Skip to content

fix(solid): publish the draft as its checks read it - #668

Merged
ixuz merged 1 commit into
mainfrom
fix/publish-what-was-checked
Nov 8, 2026
Merged

ixuz merged 1 commit into
mainfrom
fix/publish-what-was-checked

Conversation

@ixuz

@ixuz ixuz commented Nov 8, 2026

Copy link
Copy Markdown
Member

What and why

Publishing checked a draft on one read and then assembled the release
from its documents read again, accepting the second read when each
document's ETag was unchanged. A server may send no ETag, or the same
one for other content, so a release could be written from content the
release rules, the Markdown check and the shapes never saw, and the
draft then marked released from that read too.

assemble now builds the release from the read at the version it is
given, as the repository holds it, without reading again, and refuses
with changedElsewhere when that read is no longer the draft's last. A
version now names the read itself rather than the server's ETags: a
document read again is a new read unless the pod answers 304. Download
still assembles from a fresh read, since it runs no checks.

On a pod that sends no ETag, a re-read of the draft during a publish
(for example a refetch when the tab regains focus) now refuses that
publish with changedElsewhere; publishing again succeeds. docs/studio.md
and docs/data-model.md describe the rule.

Refs: GHSA-438x-f779-7chm

Publishing checked a draft on one read and then assembled the release
from its documents read again, accepting the second read when each
document's ETag was the same. A server may give no ETag, or the same
one for other content, so a release could be written from content the
release rules, the Markdown check and the shapes never saw, and the
draft then marked released from that read too.

assemble now makes the release from the read at the version it is
given, as the repository holds it, without reading again, and refuses
with changedElsewhere when that read is no longer the draft's last. A
version now names the read itself: a document read again is a new read
unless the pod answers 304, so a draft read anew in between is never
taken for the one checked, whatever its ETags say.

Refs: GHSA-438x-f779-7chm
@ixuz ixuz added bug Something isn't working interop labels Nov 8, 2026
@ixuz
ixuz enabled auto-merge November 8, 2026 17:08
@ixuz
ixuz added this pull request to the merge queue Nov 8, 2026
Merged via the queue into main with commit f42a79c Nov 8, 2026
51 checks passed
@ixuz
ixuz deleted the fix/publish-what-was-checked branch November 8, 2026 17:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working interop

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant