@optimystic/db-p2p 1.0.0-beta.3 → 1.0.0

package/src/cluster/commit-proof.ts

@@ -300,8 +300,8 @@ function isVoteMap(value: unknown): value is Record<string, Signature> {
  * Count distinct `approve` votes over `hash` from signers inside `peerSet`, verifying each signature
  * against the Ed25519 key its peer id names. Per-entry rules (the spec's step 5/6):
  *
- * - a non-`approve` vote is ignored silently (rejects/conflicts are part of the signed record but
- *   never count toward approval);
+ * - a non-`approve` vote is ignored silently (rejects and the two transient refusals, `conflict` and
+ *   `held`, are part of the signed record but never count toward approval);
  * - a signer outside `peerSet` is skipped and noted (`sawUnknownSigner`) — the caller downgrades a
  *   failed threshold to `unknown-signer`;
  * - a signer inside `peerSet` whose id is not a valid Ed25519 peer id → immediate

package/src/cluster/race-resolution.ts

@@ -98,9 +98,11 @@ export function resolveRace(existing: ClusterRecord, incoming: ClusterRecord): '
 
 /**
  * Aged advisory priority carried by a record's pend operation, clamped to [0, MaxPriority].
- * The multi-collection path carries it on `pend.validation.transaction.priority`; the single-collection
- * (`Collection.sync`) path carries it as top-level `pend.priority`; a record with neither — a
- * legacy/unversioned coordinator's transaction, or a non-pend operation — is priority 0
+ * A validated multi-collection pend carries it on `pend.validation.transaction.priority`; a pend
+ * without a transaction — the single-collection (`Collection.sync`) path, and a coordinator built
+ * with `pendValidation: 'none'` (the Quereus adapter's legacy multi-tree commit) — carries it as
+ * top-level `pend.priority`; a record with neither — an unversioned coordinator's transaction, or a
+ * non-pend operation — is priority 0
  * (backward compatible: such transactions simply never age). Both carriers live inside the signed
  * `message`, so priority is integrity-protected in transit; clamping here bounds a self-asserted
  * out-of-range value to the cap.
@@ -126,10 +128,52 @@ export function recordPriority(record: ClusterRecord): number {
 }
 
 /**
- * Whether two messages must serialize against each other: true when they touch a common block AND
- * are not the same action. The same-action escape is what lets a commit follow its own pend — both
- * name every block the action writes, so a bare overlap test would have each transaction blocking
- * its own next phase. Gates whether {@link resolveRace} runs at all.
+ * Whether two messages must serialize against each other: true when they touch a common block, are
+ * not the same action, and neither is cancel-only. The same-action escape is what lets a commit
+ * follow its own pend — both name every block the action writes, so a bare overlap test would have
+ * each transaction blocking its own next phase. Gates whether {@link resolveRace} runs at all.
+ *
+ * A cancel-only message commutes with every message of a different action, so it never conflicts.
+ * Cancelling action X only deletes X's pending records on the named blocks (`StorageRepo.cancel`); it
+ * never moves a block's revision, so it reorders nobody's history:
+ *   - a commit of Y never reads X's pending record (that was checked at Y's pend);
+ *   - a pend of Y is refused by storage and by `validatePendOperations` while X's record stands, in
+ *     either arrival order — the worst outcome is a retry of Y, never a wrong result;
+ *   - an invalidation writes compensating revisions and does not touch pending records.
+ * Counting the cancel as a rival was actively harmful: on a two-member cohort a single conflict vote
+ * makes super-majority unreachable, so a refused writer's cancel knocked out the WINNER's commit after
+ * its log tail had landed, and the winner tore. It also let a pend or commit abort a cancel's own
+ * reservation, leaving the refused pending records standing longer.
+ *
+ * A commit-only message competes with nothing but an invalidation. A commit is only ever sent for an
+ * action whose pend already WON its slot (the race above ran at the pend, and storage holds that
+ * pend's record); the commit only promotes that record, so there is no contest left for it to lose:
+ *   - a pend of Y: storage and `validatePendOperations` refuse it while X's record stands and Y has
+ *     not built on it (`isReservationAgainst`: Y asks for X's slot or an earlier one, or — at the vote
+ *     of a cohort that can leave a member out — the base Y declares for the block is below X's slot),
+ *     and refuse it as stale once X has committed
+ *     there — the worst outcome is a retry of Y. A Y that built on X (it read the block, and
+ *     `StorageRepo.get` promotes X's record for a reader whose log names X) lands after X: Y's pend
+ *     declares X's revision as its base, and a member X has not reached yet refuses Y as behind (the
+ *     fork guard in `StorageRepo.internalCommit`) and reconciles, rather than applying Y over the older
+ *     base. That guard reads the base Y's pend carried for the block (`PendRequest.baseRevs`, stored
+ *     with the record) and falls back to the base Y's commit declared. A Y that read the block WITHOUT
+ *     X's change — from four members up, from a member that never received X's pend — declares the
+ *     pre-X base, and every member still holding X's record holds it at the vote, however far past
+ *     X's slot Y asks (that shape needs a member outside X's promise quorum, which is exactly where
+ *     the vote reads Y's base — `cohortCanMissAPend`). What neither closes is a Y from a sender that names no base at all (an older build;
+ *     accepted as the residual, see docs/internals.md "An update-only transform is applied only to
+ *     the base its author read"). Counting the commit as a rival never closed any of these: it only
+ *     fired while X's commit was still in its own promise round at a member, and when the race went
+ *     Y's way it tore X instead;
+ *   - a commit of Y: `StorageRepo.commit` never looks at another action's pending record; its own
+ *     stale and fork checks, and `validateCommitRevisions` at the vote, order the two under the block
+ *     latch.
+ * Counting either as a rival was the same tear as the cancel's, one step later: on a two-member cohort
+ * a writer whose log tail had just landed had its data-block commit knocked out by the NEXT writer's
+ * pend (which had read, and was building on, exactly that commit), so the next writer's revision
+ * landed over a member that never took the first one, and the first writer tore. An invalidation
+ * still serializes against a commit: it writes compensating revisions to the same blocks.
  */
 export function operationsConflict(ops1: RepoMessage['operations'], ops2: RepoMessage['operations']): boolean {
 	// Check if one is a commit for the same action as a pend - these don't conflict
@@ -140,6 +184,14 @@ export function operationsConflict(ops1: RepoMessage['operations'], ops2: RepoMe
 		return false;
 	}
 
+	if (isCancelOnly(ops1) || isCancelOnly(ops2)) {
+		return false;
+	}
+
+	if ((isCommitOnly(ops1) && !invalidates(ops2)) || (isCommitOnly(ops2) && !invalidates(ops1))) {
+		return false;
+	}
+
 	const blocks1 = new Set(getAffectedBlockIds(ops1));
 	const blocks2 = new Set(getAffectedBlockIds(ops2));
 
@@ -156,3 +208,20 @@ export function operationsConflict(ops1: RepoMessage['operations'], ops2: RepoMe
 
 	return false;
 }
+
+/**
+ * Every operation is a cancel. Stated over the whole list, although a `RepoMessage` carries one
+ * operation in practice, so a mixed message stays conservative and keeps conflicting.
+ */
+function isCancelOnly(operations: RepoMessage['operations']): boolean {
+	return operations.length > 0 && operations.every(operation => 'cancel' in operation);
+}
+
+/** Every operation is a commit — conservative on a mixed list, like {@link isCancelOnly}. */
+function isCommitOnly(operations: RepoMessage['operations']): boolean {
+	return operations.length > 0 && operations.every(operation => 'commit' in operation);
+}
+
+function invalidates(operations: RepoMessage['operations']): boolean {
+	return operations.some(operation => 'invalidate' in operation);
+}