@optimystic/db-p2p 0.25.1 → 0.26.0

package/dist/src/cluster/cluster-repo.js

@@ -1,5 +1,5 @@
 import { blockIdsForTransforms, isOwnRevision, DEFAULT_SUPER_MAJORITY_THRESHOLD } from "@optimystic/db-core";
-import { computeClusterCommitHash, computeClusterMessageHash, computeClusterPromiseHash, membershipDigest, recordMembershipDigest, clampPriority, clusterVoteSigningPayload, clusterVoteVerificationPayload } from "@optimystic/db-core";
+import { computeClusterCommitHash, computeClusterMessageHash, computeClusterPromiseHash, membershipDigest, recordMembershipDigest, clusterVoteSigningPayload, clusterVoteVerificationPayload } from "@optimystic/db-core";
 import { verifyInvalidationCertificate } from "../dispute/invalidation.js";
 import { buildCommitCert, invalidationActionId } from "./commit-cert.js";
 import { ClusterClient } from "./client.js";
@@ -11,6 +11,8 @@ import { createLogger } from '../logger.js';
 import { PenaltyReason } from "../reputation/types.js";
 import { isMissingBaseRevisionFailure } from "../storage/storage-repo.js";
 import { checkPendValidation } from "../pend-validation.js";
+import { getAffectedBlockIds } from "./record-operations.js";
+import { operationsConflict, resolveRace } from "./race-resolution.js";
 import { buildBlockCommitProof } from "./commit-proof.js";
 import { RECONCILE_TIMEOUT_MS } from "./reconcile-block.js";
 const log = createLogger('cluster-member');
@@ -44,10 +46,17 @@ export const CONTENT_DIGEST_MISMATCH = 'content-digest-mismatch';
  */
 export { PEND_NOT_VALIDATABLE, VALIDATOR_FAULT } from "../pend-validation.js";
 export function clusterMember(components) {
-    return new ClusterMember(components.storageRepo, components.peerNetwork, components.peerId, components.privateKey, components.protocolPrefix, components.partitionDetector, components.fretService, components.validator, components.reputation, components.consensusConfig, components.stateStore, components.reconcileBlock, components.onCommitCertificate, components.onInvalidate, components.recomputeArbitratorSet, components.deriveExpectedCluster);
+    return new ClusterMember(components.storageRepo, components.peerNetwork, components.peerId, components.privateKey, components.protocolPrefix, components.partitionDetector, components.fretService, components.validator, components.reputation, components.consensusConfig, components.stateStore, components.reconcileBlock, components.onCommitCertificate, components.onInvalidate, components.recomputeArbitratorSet, components.deriveExpectedCluster, components.now);
 }
 // How long to keep executed transaction records (10 minutes)
 const ExecutedTransactionTtlMs = 10 * 60 * 1000;
+/**
+ * How long a held reservation may go untouched before the conflict scan ({@link ClusterMember.findConflict})
+ * sweeps it. Generous relative to a round-trip: the scan frees an ABANDONED coordinator's blocks, so
+ * sweeping too eagerly would drop a live transaction whose next delivery is merely in flight.
+ * Exported so a test can advance an injected clock past it without restating the number.
+ */
+export const CONFLICT_STALE_THRESHOLD_MS = 2000;
 // Upper bound on an awaited active reconciliation of a divergent commit. Bounds the
 // consensus path so a slow/unreachable cohort peer can't stall the cluster stream;
 // a timeout is logged and tolerated (never thrown — that would reset the stream).
@@ -134,9 +143,11 @@ export class ClusterMember {
     /** What a validator-configured member does with a pend carrying no `validation` payload — see
      * {@link ClusterConsensusConfig.unvalidatablePendPolicy}. Read once, like the gate parameters. */
     unvalidatablePendPolicy;
+    /** Clock behind the reservation table's `lastUpdate` — see {@link ClusterMemberComponents.now}. */
+    now;
     constructor(storageRepo, peerNetwork, peerId, privateKey, protocolPrefix, 
     // Reserved for partition-healing (backlog ticket 6.5-partition-healing); held but not yet consumed.
-    _partitionDetector, fretService, validator, reputation, consensusConfig, stateStore, reconcileBlock, onCommitCertificate, onInvalidate, recomputeArbitratorSet, deriveExpectedCluster) {
+    _partitionDetector, fretService, validator, reputation, consensusConfig, stateStore, reconcileBlock, onCommitCertificate, onInvalidate, recomputeArbitratorSet, deriveExpectedCluster, now) {
         this.storageRepo = storageRepo;
         this.peerNetwork = peerNetwork;
         this.peerId = peerId;
@@ -151,6 +162,7 @@ export class ClusterMember {
         this.onInvalidate = onInvalidate;
         this.recomputeArbitratorSet = recomputeArbitratorSet;
         this.deriveExpectedCluster = deriveExpectedCluster;
+        this.now = now ?? (() => Date.now());
         this.superMajorityThreshold = consensusConfig?.superMajorityThreshold ?? DEFAULT_SUPER_MAJORITY_THRESHOLD;
         this.minAbsoluteClusterSize = consensusConfig?.minAbsoluteClusterSize ?? 3;
         this.clusterSizeTolerance = consensusConfig?.clusterSizeTolerance ?? 0.5;
@@ -406,7 +418,7 @@ export class ClusterMember {
             const timeouts = this.setupTimeouts(currentRecord);
             this.activeTransactions.set(record.messageHash, {
                 record: currentRecord,
-                lastUpdate: Date.now(),
+                lastUpdate: this.now(),
                 promiseTimeout: timeouts.promiseTimeout,
                 resolutionTimeout: timeouts.resolutionTimeout
             });
@@ -829,8 +841,16 @@ export class ClusterMember {
      *  3. **Consistency with the derived view** — `|D △ E|` within `clusterSizeTolerance·|E|`; honest churn
      *     of a peer or two is absorbed, a wholesale-disjoint or half-size set is not.
      *
-     * **Fail-closed posture.** When the member cannot confidently derive `E` (no capability, low FRET
-     * confidence — exactly what a partition induces), it must refuse any *downsizing* decision — but it
+     * **Inadmissible records come first.** Before any of that, a member that CAN derive refuses outright a
+     * record whose coordinating block is the sender's free choice rather than a fact about the record: one
+     * that names no coordinating block at all, or names a block the record's own operations never touch.
+     * Those are defects of the SENDER, and no current coordinator produces them; treating them as "cannot
+     * derive" would hand a dishonest coordinator the choice of which check every member ran. A member with
+     * no derivation capability never reaches this refusal — it has nothing to check against.
+     *
+     * **Fail-closed posture.** When the member cannot confidently derive `E` — no capability, a bound
+     * block whose lookup failed or returned an empty/low-confidence view (low FRET confidence is exactly
+     * what a partition induces) — it must refuse any *downsizing* decision — but it
      * needs a size reference to judge "downsize" against, and it may NOT borrow `clusterSize` for that:
      * `clusterSize` is the replication factor (what a cohort should aim for), not a claim about how many
      * peers exist, so a small deployment configured with the default 10 would refuse every write. The
@@ -853,11 +873,56 @@ export class ClusterMember {
             return { admit: false, reason: `${MEMBERSHIP_NOT_ADMITTED}:self-not-member` };
         }
         // Explicit opt-in: knowingly transact below the safe floor (single-node / local dev). Skips the
-        // size/consistency gates but not self-membership above.
+        // size/consistency gates AND the record-shape refusals below, but not self-membership above: it
+        // already bypasses the far stronger confident predicates, so making a weaker check the one thing it
+        // cannot bypass would be incoherent.
         if (this.allowUnvalidatedSmallCluster) {
             return { admit: true };
         }
-        const derived = await this.deriveExpectedClusterView(record);
+        const derivation = await this.deriveExpectedClusterView(record);
+        // Split the sender's faults from this member's own. A record that names no coordinating block, or
+        // names one its own operations never touch, is one no current coordinator builds (every production
+        // sender goes through `ClusterCoordinator.executeClusterTransaction`, which stamps a bound id) — so
+        // it is inadmissible, not merely underived. Collapsing these into the lenient fallback let a
+        // dishonest coordinator choose which check every member ran, just by how it filled one field.
+        // Exhaustive switch on purpose: a future `kind` must not silently join the lenient bucket.
+        switch (derivation.kind) {
+            case 'unusable-record': {
+                log('cluster-member:admission-reject', {
+                    messageHash: record.messageHash,
+                    reason: derivation.variant,
+                    declaredSize: declared.length
+                });
+                // The count of affected block ids, not the list: this string is signed into the vote and lands
+                // in dispute records, so a wide multi-block pend must not produce an unbounded reason.
+                // NOTE: `blockId` itself is copied verbatim from the (untrusted) record and nothing upstream
+                // bounds its length — fine while block ids are short content hashes; if a record ever carries
+                // a pathological id, truncate it here rather than signing an arbitrarily large reason string.
+                // A fresh record carries no signatures, so `validateRecord` does not authenticate the sender
+                // before this point; what keeps it harmless is that the reason is bounded by the record the
+                // sender already transmitted (no amplification), not that the path is authenticated.
+                return {
+                    admit: false,
+                    reason: derivation.variant === 'no-coordinating-block'
+                        ? `${MEMBERSHIP_NOT_ADMITTED}:no-coordinating-block`
+                        : `${MEMBERSHIP_NOT_ADMITTED}:unbound-coordinating-block (blockId=${derivation.blockId}, affected=${derivation.affected})`
+                };
+            }
+            // Receiver-side outcomes: a resolved view, no capability at all, or a bound block whose lookup
+            // failed. All three keep today's behaviour, judged below.
+            case 'view':
+            case 'no-capability':
+            case 'underivable':
+                break;
+            default: {
+                // `never` is the compile-time half of the guard: adding a `kind` without deciding its side
+                // of the sender/receiver split fails the build here. The runtime half returns a real
+                // verdict — fail closed — rather than the derivation object, which is not one.
+                const exhaustive = derivation;
+                return { admit: false, reason: `${MEMBERSHIP_NOT_ADMITTED}:${exhaustive.kind}` };
+            }
+        }
+        const derived = derivation.kind === 'view' ? derivation.view : undefined;
         // An empty derived view (kEst === 0) carries no usable reference set: measured against it every
         // non-empty declared set is wholly "inconsistent" (maxDiff = ceil(tol·0) = 0), which would spuriously
         // reject a legitimate full cluster — a stricter, worse outcome than an absent view. Treat empty as
@@ -952,23 +1017,43 @@ export class ClusterMember {
         return Math.max(this.minAbsoluteClusterSize, Number.isFinite(scaled) ? scaled : 0);
     }
     /**
-     * Derive this member's own view of the record's block cluster via the injected capability, or
-     * `undefined` when it cannot (no capability, no coordinating block id, a coordinating block not bound
-     * to the record's own operations, or a derivation error — all of which the gate treats as "not
-     * confident"). Derived from the record's coordinating block, the same key the coordinator used to
-     * select the cluster.
+     * Derive this member's own view of the record's block cluster via the injected capability, reporting
+     * *why* when it cannot — see {@link ClusterViewDerivation}. Four outcomes, deliberately not collapsed
+     * into one `undefined`: the member has no capability; the lookup failed; the record named no
+     * coordinating block; the record named a block its own operations never touch. The last two are the
+     * sender's choices and {@link admitMembership} refuses them; the first two are this member's own
+     * limitation and stay lenient. Derived from the record's coordinating block, the same key the
+     * coordinator used to select the cluster.
      *
      * Read off `record.message`, NOT a top-level record field: `messageHash` covers the message only, so
      * only the in-message copy is tamper-evident to a relaying peer. (There is no top-level copy any more —
      * see {@link ClusterRecord.message}.)
      */
     async deriveExpectedClusterView(record) {
+        // Capability check FIRST, before the record's field is even read: a member with nothing to derive
+        // against must never report a sender fault — it has no standing to judge the record's shape.
         if (!this.deriveExpectedCluster) {
-            return undefined;
+            return { kind: 'no-capability' };
         }
+        // NOTE: only `coordinatingBlockIds[0]` is read. A pend may declare the whole consolidated batch
+        // here; the gate needs one block to derive a cohort from, and the coordinator's choke point puts
+        // the cohort key it actually selected against at index 0.
         const blockId = record.message.coordinatingBlockIds?.[0];
         if (blockId === undefined) {
-            return undefined;
+            // Covers both an absent field and a present-but-empty array — distinct wire shapes, same
+            // defect: the record names nothing to derive from. Every production sender routes through
+            // `ClusterCoordinator.executeClusterTransaction`, which stamps a bound id when the message has
+            // none, so no honest record reaches here.
+            //
+            // No rolling-upgrade gate guards this refusal, and `membershipVersion` is NOT that gate:
+            // `validateRecord` accepts v1 and unversioned records, and the choke point that stamps the
+            // field onto commit/cancel records (`commit-and-cancel-records-omit-the-coordinating-block`)
+            // landed without bumping the version — so a peer on a build older than that one sends
+            // commit/cancel records this refuses. The decision is that cluster consensus deploys as one
+            // unit and this project makes no cross-build compatibility promise; if that ever changes,
+            // the gate belongs here (admit an unversioned record on the lenient path), not in the caller.
+            log('cluster-member:coordinating-block-absent', { messageHash: record.messageHash });
+            return { kind: 'unusable-record', variant: 'no-coordinating-block' };
         }
         // Hashing the field makes it tamper-evident to RELAYS, but the coordinator is the party this gate
         // exists to check and it picks the field before it computes the hash. Unbound, a Byzantine
@@ -978,14 +1063,21 @@ export class ClusterMember {
         // record's OWN operations touch removes that free choice. `getAffectedBlockIds` is the same block
         // extraction conflict detection already runs on this message — one definition, so the set a
         // coordinating id must come from cannot drift from the set the record is judged to touch.
-        if (!this.getAffectedBlockIds(record.message.operations).includes(blockId)) {
+        const affected = getAffectedBlockIds(record.message.operations);
+        if (!affected.includes(blockId)) {
             log('cluster-member:coordinating-block-unbound', {
                 messageHash: record.messageHash,
                 coordinatingBlockId: blockId
             });
-            // Fail closed into the branch that already exists rather than throwing: a hard reject would
-            // change `validateRecord`'s failure surface, and "not confident" already refuses any downsize.
-            return undefined;
+            // Refuse, do not fall back: the fallback floor is the posture for a fault of THIS member, and
+            // letting a sender-chosen defect land there let the coordinator pick which check ran. Reported
+            // as a reject vote rather than a throw so the member emits a signed `reject` and dispute
+            // accounting keeps working — this stays out of `validateRecord`'s failure surface.
+            //
+            // `affected` is empty for a record with no operations, so any named block is unbound and the
+            // record is refused — correct (a record with no operations is malformed), and why `affected=0`
+            // can legitimately appear in the reason string.
+            return { kind: 'unusable-record', variant: 'unbound-coordinating-block', blockId, affected: affected.length };
         }
         // Which block a member derived its cohort view from is the single most useful fact when an
         // admission decision has to be explained after the fact — and the only externally visible sign
@@ -995,11 +1087,14 @@ export class ClusterMember {
             // NOTE: derives (findCluster) once per inbound record on the promise path — one routing lookup
             // per vote. If this shows up as hot, cache the derived view per (blockId, short TTL): it is a
             // pure read of current topology, so a few-seconds-stale view is safe for admission.
-            return await this.deriveExpectedCluster(blockId);
+            return { kind: 'view', view: await this.deriveExpectedCluster(blockId) };
         }
         catch (err) {
             log('cluster-member:derive-expected-cluster-error', { messageHash: record.messageHash, error: err.message });
-            return undefined;
+            // Receiver fault: a bound block whose lookup threw. Stays lenient (the `assumedClusterSize`
+            // fallback) — that is the partition posture, and refusing here would make a transient routing
+            // hiccup refuse every write.
+            return { kind: 'underivable' };
         }
     }
     /** |A △ B| over two id lists (order-independent set symmetric difference). */
@@ -1811,27 +1906,36 @@ export class ClusterMember {
      * entries are swept, and a held transaction that LOSES the race to `record` is cleared.
      */
     findConflict(record) {
-        const now = Date.now();
-        const staleThresholdMs = 2000; // 2 seconds - allow more time for distributed consensus
-        const incomingBlockIds = this.getAffectedBlockIds(record.message.operations);
+        // Same clock as the `lastUpdate` stamp (the `shouldPersist` set and `persistParticipantState`),
+        // so an injected test clock ages entries instead of putting stamp and comparison on different bases.
+        const now = this.now();
+        const incomingBlockIds = getAffectedBlockIds(record.message.operations);
         log('cluster-member:findConflict-check', {
             messageHash: record.messageHash,
             activeCount: this.activeTransactions.size,
             incomingBlockIds
         });
         for (const [existingHash, state] of Array.from(this.activeTransactions.entries())) {
+            // Defensive only — no caller can reach it today. `getTransactionPhase` calls this scan solely
+            // when `!record.promises[ourId]`, and every write into `activeTransactions` already carries our
+            // vote (the `shouldPersist` set happens after the phase loop recorded it; `recoverTransactions`
+            // restores what that same branch persisted; `handleExpiration` re-sets with our reject added).
+            // A redelivery at a known hash is merged with the held record first (`mergeRecords`, first-seen
+            // wins), so our vote is present by the time the phase is computed. Kept because the scan is on
+            // the vote path, where self-blocking would be silent and permanent.
             if (existingHash === record.messageHash) {
                 continue;
             }
-            const existingBlockIds = this.getAffectedBlockIds(state.record.message.operations);
+            const existingBlockIds = getAffectedBlockIds(state.record.message.operations);
             log('cluster-member:findConflict-compare', {
                 existing: existingHash,
                 incoming: record.messageHash,
                 existingBlockIds,
                 incomingBlockIds
             });
-            // Clean up stale transactions that have been around too long
-            if (now - state.lastUpdate > staleThresholdMs) {
+            // Sweep abandoned reservations BEFORE the race is decided: an entry nobody is driving any
+            // more must not win a contest it should not be in and block a live rival for its whole life.
+            if (now - state.lastUpdate > CONFLICT_STALE_THRESHOLD_MS) {
                 log('cluster-member:stale-cleanup', {
                     messageHash: existingHash,
                     age: now - state.lastUpdate
@@ -1839,9 +1943,9 @@ export class ClusterMember {
                 this.clearTransaction(existingHash);
                 continue;
             }
-            if (this.operationsConflict(state.record.message.operations, record.message.operations)) {
+            if (operationsConflict(state.record.message.operations, record.message.operations)) {
                 // Use race resolution to determine winner
-                const resolution = this.resolveRace(state.record, record);
+                const resolution = resolveRace(state.record, record);
                 if (resolution === 'keep-existing') {
                     log('cluster-member:race-keep-existing', {
                         existing: existingHash,
@@ -1856,181 +1960,15 @@ export class ClusterMember {
                         incoming: record.messageHash
                     });
                     this.clearTransaction(existingHash);
-                    continue; // Check other conflicts
+                    // `continue`, not `break`: the incoming transaction may overlap several held
+                    // reservations, and beating one says nothing about the rest. Stopping here would let it
+                    // walk past a second, still-live rival it actually loses to.
+                    continue;
                 }
             }
         }
         return undefined; // No blocking conflicts
     }
-    /** Number of *approve* promise votes on a record — the count the commit rule uses. */
-    static approvalCount(record) {
-        return Object.values(record.promises).filter(s => s.type === 'approve').length;
-    }
-    /**
-     * Resolve a race between two conflicting transactions. Total and deterministic, so every honest
-     * member computes the identical winner (the Theorem 1 Case-2 premise). Order:
-     *   1. more *approve* promise signatures wins  (progress monotonicity — see safety note below);
-     *   2. equal approval counts → higher aged priority wins  (fairness — see {@link recordPriority});
-     *   3. still tied → higher message hash wins.
-     *
-     * The count is APPROVALS, not `promises` keys. `promises` is the vote map — a reject occupies a key
-     * there exactly as an approve does — so counting keys would treat a rejection as progress, letting a
-     * record that can never commit outrank (and therefore block, via {@link findConflict}) a fresh rival
-     * for the whole staleness window. Approvals is also the count the invariant below actually needs:
-     * the commit rule is `approvedPromises >= superMajority`, which never looks at rejections.
-     *
-     * Approval count is FIRST so this comparison never displaces a transaction that is further along.
-     * That restores the pre-priority safety invariant: a member commits purely on promise supermajority
-     * (`handleCommitNeeded` signs whenever `approvedPromises >= superMajority`; the commit path has NO
-     * conflict re-check), so `resolveRace` is the ONLY arbiter among concurrently-pending conflicts.
-     * With approvals-first, once transaction X holds a promise supermajority every conflicting rival Y has
-     * strictly fewer approvals — Y can only match X's count by getting the intersecting quorum member to
-     * approve it, but that member already holds X at supermajority and `resolveRace(X, Y)` returns
-     * `keep-existing` on X's higher count, so it never does. By quorum intersection any Y-supermajority
-     * overlaps X's in ≥1 honest member, and that member rejects Y. One winner (docs/correctness.md
-     * Theorem 9). Priority-first would break this: it could displace an already-quorum-reached X for a
-     * higher-priority Y with fewer approvals, letting BOTH commit (split brain) — the regression fixed by
-     * ticket occ-priority-first-breaks-promise-monotonicity.
-     *
-     * Priority is now a tie-break that runs only at EQUAL approval counts, which is exactly the
-     * concurrent-starvation case aging targets (two fresh rivals, 0 promises each, otherwise coin-flipping
-     * on the hash). Priority still breaks those ties deterministically, so aging still solves the stated
-     * fairness problem in its common case. It only orders two *concurrently-pending* conflicts; it does NOT
-     * defer a fresh pend for an absent aged transaction (that residual — sequential sub-window starvation —
-     * is the deferred feat-occ-priority-reservation).
-     *
-     * NOTE: residual-fairness tripwire. Under approvals-first an aged transaction can still lose to a fresh
-     * rival that has *legitimately* gathered even one more approval — that is not the pure-coin-flip
-     * starvation aging targets (equal counts, priority wins), it is the monotonicity behaviour we WANT (a
-     * more-progressed rival is never displaced). If deeper fairness against a genuinely-more-progressed
-     * rival is ever needed, it belongs to feat-occ-priority-reservation (reserve/defer at pend time), NOT
-     * to this race tie-break.
-     *
-     * NOTE: Byzantine self-assert is a fairness DoS, not a safety hole. A coordinator can stamp
-     * priority == MaxPriority on every transaction; recordPriority clamps to the cap so it cannot
-     * exceed it, and priority never influences validity/operationsHash/stale-read checks — and now sits
-     * below the approval count, so it can only break equal-count ties it might have ~50% won anyway,
-     * degrading to at-worst-status-quo fairness (the same graceful-degradation class as spam under
-     * honest-majority). Binding priority to provable age is out of scope (feat-occ-priority-reservation).
-     *
-     * NOTE: keep priority a self-contained additive message field + this one comparison key so it
-     * composes with — does not block — a future HLC/crdt-sync redesign of this same path
-     * (design-hot-log-tail-sharding-guidance).
-     */
-    resolveRace(existing, incoming) {
-        // 1. Transaction with more APPROVALS wins — never displace a more-progressed rival (safety, see
-        // above). Counting `promises` keys instead would count reject votes as progress: a record holding
-        // one rejection would outrank an untouched rival and reserve its blocks for the whole staleness
-        // window, and the commit rule this ordering protects (`approvedPromises >= superMajority`) never
-        // looks at rejections anyway.
-        const existingCount = ClusterMember.approvalCount(existing);
-        const incomingCount = ClusterMember.approvalCount(incoming);
-        if (existingCount !== incomingCount) {
-            return existingCount > incomingCount ? 'keep-existing' : 'accept-incoming';
-        }
-        // 2. Equal approval counts → higher aged priority wins (fairness tie-break).
-        const existingPriority = this.recordPriority(existing);
-        const incomingPriority = this.recordPriority(incoming);
-        if (existingPriority !== incomingPriority) {
-            return existingPriority > incomingPriority ? 'keep-existing' : 'accept-incoming';
-        }
-        // 3. Tie-breaker: higher message hash wins (deterministic).
-        return existing.messageHash > incoming.messageHash ? 'keep-existing' : 'accept-incoming';
-    }
-    /**
-     * 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
-     * (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.
-     *
-     * NOTE: `message` is fixed for a transaction's whole lifecycle (promises/commits accrue in the
-     * separate `promises`/`commits` maps, never in `message`), so a transaction keeps its rank through
-     * the commit phase — there is no "priority drops to 0 at commit" asymmetry. resolveRace is only
-     * consulted at the promise decision (findConflict), i.e. between two still-open conflicting
-     * transactions, which is exactly the concurrent-contention case priority is meant to order.
-     */
-    recordPriority(record) {
-        for (const op of record.message.operations) {
-            if ('pend' in op) {
-                // Every hop optional: `validation` arrives off the wire inside a signed message whose
-                // hash binds its bytes, not its shape, so a malformed pair must yield priority 0 (what
-                // clampPriority already does for a missing or Byzantine number) rather than throw out
-                // of the vote path — the lost vote this fail-closed pass exists to prevent.
-                return clampPriority(op.pend.validation?.transaction?.priority ?? op.pend.priority);
-            }
-        }
-        return 0;
-    }
-    operationsConflict(ops1, ops2) {
-        // Check if one is a commit for the same action as a pend - these don't conflict
-        const actionId1 = this.getActionId(ops1);
-        const actionId2 = this.getActionId(ops2);
-        if (actionId1 && actionId2 && actionId1 === actionId2) {
-            // Same action - commit is resolving the pend, not conflicting
-            return false;
-        }
-        const blocks1 = new Set(this.getAffectedBlockIds(ops1));
-        const blocks2 = new Set(this.getAffectedBlockIds(ops2));
-        for (const block of Array.from(blocks1)) {
-            if (blocks2.has(block)) {
-                log('cluster-member:conflict-detected', {
-                    blocks1: Array.from(blocks1),
-                    blocks2: Array.from(blocks2),
-                    conflictingBlock: block
-                });
-                return true;
-            }
-        }
-        return false;
-    }
-    getActionId(operations) {
-        for (const operation of operations) {
-            if ('pend' in operation) {
-                return operation.pend.actionId;
-            }
-            else if ('commit' in operation) {
-                return operation.commit.actionId;
-            }
-            else if ('cancel' in operation) {
-                return operation.cancel.actionRef.actionId;
-            }
-        }
-        return undefined;
-    }
-    /**
-     * Every block id the message's own operations name. Two consumers, deliberately sharing one
-     * definition: conflict detection (which writes must serialize against each other) and the membership
-     * admission gate's binding check (the set a legitimate `coordinatingBlockIds[0]` must come from —
-     * {@link ClusterMember.deriveExpectedClusterView}). If the two ever disagreed, a coordinator could
-     * name a block the record is not judged to touch.
-     */
-    getAffectedBlockIds(operations) {
-        const blockIds = new Set();
-        for (const operation of operations) {
-            if ('get' in operation) {
-                operation.get.blockIds.forEach(id => blockIds.add(id));
-            }
-            else if ('pend' in operation) {
-                // Use blockIdsForTransforms to correctly extract block IDs from Transforms structure
-                blockIdsForTransforms(operation.pend.transforms).forEach(id => blockIds.add(id));
-            }
-            else if ('commit' in operation) {
-                operation.commit.blockIds.forEach(id => blockIds.add(id));
-            }
-            else if ('cancel' in operation) {
-                operation.cancel.actionRef.blockIds.forEach(id => blockIds.add(id));
-            }
-            else if ('invalidate' in operation) {
-                // The invalidation writes compensating revisions to these blocks; surfacing them lets
-                // conflict detection serialize a concurrent commit racing the invalidation on a block.
-                operation.invalidate.blockIds.forEach(id => blockIds.add(id));
-            }
-        }
-        return Array.from(blockIds);
-    }
     async propagateIfNeeded(record) {
         const promises = [];
         for (const peerId of Object.keys(record.peers)) {
@@ -2154,7 +2092,7 @@ export class ClusterMember {
         this.stateStore.saveParticipantState(messageHash, {
             messageHash,
             record,
-            lastUpdate: Date.now()
+            lastUpdate: this.now()
         }).catch(err => log('cluster-member:persist-error', { messageHash, error: err.message }));
     }
     /**