Skip to content

Decide conflicting attempts to change one artifact (GAP-CORE-016) - #18

Open
aharvard wants to merge 6 commits into
mainfrom
fix/deferred-concurrent-updates
Open

aharvard wants to merge 6 commits into
mainfrom
fix/deferred-concurrent-updates

Conversation

@aharvard

@aharvard aharvard commented Oct 14, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #17.

Problem

Step 5 said resolving concurrent updates to one artifact "remains open" and pointed to DEFERRED.md, which had no entry for it. The first version of this PR added that entry. On review, the decision was to settle the question in the draft instead of deferring it.

What the draft now decides

Rules that independent implementations must agree on are portable. Questions about which version is current stay application policy.

  • Step 3: an artifact ID and version number identify at most one artifact version. A second create under a taken number is refused and records nothing. A retry whose ArtifactVersion has the same canonical JSON bytes as the stored one does not conflict, and the implementation MAY return the stored version.
  • Step 5: an artifact version is released at most once, including after withdrawal; to release the same content again, create a new version. A release has at most one withdrawal.
  • Step 5, new "Concurrent attempts" paragraph:
    • The conflict check runs when the record is written, inside the same atomic write, not at preview time.
    • The first attempt recorded takes effect. Each later conflicting attempt is refused and records nothing.
    • The refused participant MUST be told the attempt was refused, and SHOULD be told which record it conflicted with. GAP defines no error format.
  • Stays application policy: refusing a change prepared from a version that is no longer current, for example the research and issue-tracking demos' expected-version checks. GAP doesn't define "current", so it can't define "out of date". No GAP record gains a base-version field, so nothing changes on the wire.
  • Scope list: detecting changes prepared from an out-of-date version is listed under application workflows.

Conformance and deferred ledger

  • New GAP-CORE-016 Conflicting attempts, with existing CMS, issue-tracking and research tests as coverage. Its notes state the limits.
  • One new research test: a second withdrawal of the same release is refused and leaves the workspace bytes unchanged.
  • The DEFERRED.md entry this PR added is removed. "Distributed record stores and replication" now covers only conflicts across stores and links to the new rules.

Found along the way

The CMS demo's generic create and release paths take no lock. Two overlapping createArtifactVersion calls both report success, and only one version is stored. Filed as #19, kept out of this PR.

Checks run (at c396d94)

  • pnpm test:demo: 142 pass
  • pnpm typecheck:demo
  • pnpm check:specification
  • pnpm docs:build
  • pnpm docs:test: 16 pass

@aharvard
aharvard requested a review from daveh-beep as a code owner October 14, 2026 12:47
Coder Heavy added 3 commits October 14, 2026 08:53
Step 3 makes an artifact ID and version number name at most one version.
Step 5 releases a version at most once, allows at most one withdrawal per
release, and adds Concurrent attempts: the conflict check runs when the
record is written, the first attempt recorded wins, later conflicting
attempts are refused, record nothing, and are reported to the participant.
Detecting a change prepared from a version that is no longer current stays
application policy, so no GAP record gains a base-version field.
Covers the new at-most-one-withdrawal rule: the refused attempt throws
and leaves the workspace bytes unchanged.
The draft now decides conflicting attempts within one store, so the
deferred entry is removed. The distributed-stores entry keeps only
conflicts across stores and links to the new rules. GAP-CORE-016 lists
existing demo coverage and notes that the CMS takes no lock.
@aharvard aharvard changed the title Add DEFERRED entry for concurrent updates to one artifact Decide conflicting attempts to change one artifact (GAP-CORE-016) Oct 14, 2026
Review on #18: step 3's retry allowance contradicted GAP-CORE-016's
must-refuse rule. An attempt whose ArtifactVersion has the same canonical
JSON bytes as the stored one now explicitly does not conflict, in step 3,
Concurrent attempts, and the GAP-CORE-016 statement. authoredBy is in the
record, so another participant's attempt is never identical.

Also: describe both CMS numbering paths, open Concurrent attempts with
attempts from one participant or several, and correct the GAP-CORE-016
note on CMS locking (the blog-post save holds its own lock).

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Step 5 points to DEFERRED.md for "resolution of concurrent updates", but no entry covers it

1 participant