Is the 2026-07-07 04:05 uncommanded-deletion anomaly a named failure mode, and does the literature prefer a standard fix over 'revert forward and flag it'?

concurrent-systemsrace-conditionstoctoulost-updateoptimistic-concurrency-controlcweconcurrency-control-history

The hook: on 2026-07-07 at 04:05, a periodic timer swept up and deleted content that a foreground write was still in the process of committing (the anomaly introduced in commit bd2f51a, reverted in 7deae5b). The question is whether concurrent/distributed-systems literature already has a name for "a background sweep races an in-flight foreground write," and whether that literature prescribes a standard fix — optimistic locking, event sourcing — that would have handled the incident better than the practitioner response actually taken (revert forward and flag it).

Three primary sources were read directly for this capture: MITRE's own CWE-367 and CWE-362 weakness-taxonomy pages (archived, sha recorded above and below), and Kung & Robinson's 1981 ACM TODS paper "On Optimistic Methods for Concurrency Control" (fetched from the authors' own eecs.harvard.edu hosting). All three resolved cleanly over verified TLS.

Claim: The anomaly's shape is a named, formally classified failure mode — CWE-367 (TOCTOU), child of CWE-362 — and that classification's own stated mitigations are atomicity and locking, not optimistic concurrency or event sourcing

MITRE's CWE-367 defines the weakness class directly: "The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check." A timer that sweeps based on a check of resource state (e.g., "this write looks stale/orphaned, safe to delete") racing a foreground write that is still committing is a textbook instance of this shape: check (the sweep's staleness test) and use (the delete) are separated by a window the foreground write can fall into. This is the same class the vault has already anchored to a concrete, in-the-wild instance via claim-cve-2025-38352-timer-sweep-toctou (a Linux kernel POSIX-CPU-timer sweep racing a concurrent deletion, CWE-367, CISA KEV).

Critically, CWE-367's own "Potential Mitigations" section — read in full, not excerpted by a summarizer — lists exactly six remedies, and none of them is optimistic locking or event sourcing: don't check before use at all; limit interleaving of operations across processes; shrink the check-to-use time window when atomicity isn't possible; recheck the resource after use; use an "environmental locking mechanism"; and, explicitly, "Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use." The parent class CWE-362 ("Concurrent Execution using Shared Resource with Improper Synchronization") likewise lists only synchronization primitives, mutexes, atomic operations, and least-privilege as mitigations — again, no mention of optimistic concurrency control or event sourcing anywhere on either page.

source_url: "https://cwe.mitre.org/data/definitions/367.html" source_title: "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition" source_author: "MITRE Corporation / CWE Content Team" source_date: "2026-10-28" source_venue: "Common Weakness Enumeration (CWE), DHS CISA-sponsored" source_tier: 1 source_sha: a39970c0d78b30307c4efc90bbf1db9faeb91ae31ce35e427c9bbf829be32611 source_quote: "The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check." source_quote_2: "Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use."

source_url_2: "https://cwe.mitre.org/data/definitions/362.html" source_title_2: "CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization" source_author_2: "MITRE Corporation / CWE Content Team" source_date_2: "2026-10-28" source_venue_2: "Common Weakness Enumeration (CWE), DHS CISA-sponsored" source_tier_2: 1 source_sha_2: 45eb73f07c50ebbe86d3b0b742eb1a6efcc42d4b5737deeb610d68dc86876070 source_quote_3: "Use atomic operations on shared variables."

Claim: Optimistic locking's actual ancestor is "optimistic concurrency control" (Kung & Robinson, 1981), a database-transaction technique that detects a conflicting concurrent write after the fact and responds by aborting and restarting the losing transaction — not by preventing the race up front

H.T. Kung and John T. Robinson's 1981 ACM Transactions on Database Systems paper "On Optimistic Methods for Concurrency Control" is the foundational source for what is colloquially called "optimistic locking" today. The paper proposes concurrency control built on a read phase, a validation phase, and a write phase, in which "all writes take place on local copies of the nodes to be modified" during the read phase, and a global commit only happens if validation at the end detects no conflicting concurrent transaction. The paper's own framing: "The methods used are 'optimistic' in the sense that they rely mainly on transaction backup as a control mechanism, 'hoping' that conflicts between transactions will not occur." When validation fails, the fix is not silent repair — "If validation does fail, the transaction will be backed up and start over again as a new transaction." The paper's own conclusion section is explicit that this is one of exactly two control mechanisms practice relies on — "locking and backup" — and frames optimistic methods as orthogonal to locking, trading wait-and-block for detect-and-restart.

This matters for the anomaly: optimistic concurrency control (OCC) is the database-transaction-theory answer to the lost-update shape (the vault's claim-lost-update-p4-distinct-from-toctou already establishes lost update/P4 as a separate 20th-century naming tradition from TOCTOU), and it is a detect-after-the-fact, abort-and-retry discipline — structurally closer to "notice the clobber, then correct it" than to a pre-emptive lock. The 2026-07-07 incident's actual response (revert forward and flag) is, in that light, the manual analogue of OCC's "backed up and start over" step, just performed by a human after the fact rather than by a validation routine before the write was ever allowed to appear to succeed.

source_url: "https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf" source_title: "On Optimistic Methods for Concurrency Control" source_author: "H.T. Kung and John T. Robinson" source_date: "1981-06 (ACM Transactions on Database Systems, Vol. 6, No. 2, pp. 213-226)" source_venue: "ACM Transactions on Database Systems" source_tier: 1 source_sha: 5bd2f2e7b2356de972e7e6bd19ebc229568dd7968bc01acc3583038003ce364e source_quote: "The methods used are "optimistic" in the sense that they rely mainly on transaction backup as a control mechanism, "hoping" that conflicts between transactions will not occur." source_quote_2: "If validation does fail, the transaction will be backed up and start over again as a new transaction." source_delight: "The paper that gave 'optimistic locking' its name is a 14-page ACM TODS paper still hosted free on its own author's Harvard faculty page, forty-five years on."

Claim: No primary source found recommends optimistic concurrency control or event sourcing specifically as the standard fix for a timer-sweep-vs-foreground-write race — the TOCTOU tradition's own literature prescribes atomicity/locking instead, so the premise that OCC or event sourcing is literature's "standard fix" for this exact shape is unverified

The core question asks whether concurrent-systems literature suggests a standard fix — "optimistic locking, event sourcing" — better than "revert forward and flag it." Having read CWE-367 and CWE-362 (the formal taxonomy for this exact check-then-act shape) in full, their own "Potential Mitigations" sections prescribe atomicity, synchronization primitives, and lock-before-check — never optimistic concurrency control and never event sourcing. Optimistic concurrency control is real, foundational, and well-documented (Claim 2 above), but it answers a different question — how to let concurrent transactions proceed without blocking, catching conflicts at commit time — not the specific sweep-vs.-write TOCTOU shape, for which the field's own literature reaches for locking and atomicity instead. A general web search for "event sourcing" as a fix for lost-update/sweep races turned up only secondary commentary (a DEV Community post, a Confluent engineering blog) arguing that append-only logs do not by themselves prevent a lost update without an added optimistic-concurrency check on the stream's expected version — none of which clears the Tier 1-2 floor for a technical- mechanism claim, and none of which is a primary source actually recommending event sourcing for this failure shape.

This is a case of "could not fully confirm or deny" rather than a clean answer. It is confirmed that the anomaly's shape is a named, formally classified failure mode (CWE-367/362, a crisp "yes" to the first half of the question). It is not confirmed that the literature converges on optimistic locking or event sourcing as the standard fix for this particular shape, better than revert-and-flag — the one body of literature that formally classifies this exact shape (CWE) prescribes something else (atomicity/locking), and the literature that does champion optimistic concurrency control is answering a related but distinct problem (lost update in transaction processing, per claim-lost-update-p4-distinct-from-toctou). The second half of the topic question is marked [unverified -- could not confirm or deny after search].

Further leads

• Forward-recovery vs. backward-recovery vocabulary (fault-tolerant/transactional-systems literature: a repair that "undoes" state vs. one that "repairs forward and keeps going") may be the better conceptual match for "revert forward and flag it" than OCC is — but the sources found (USPTO patents, a Univ. of Malta thesis chapter, Helsinki/Aalborg course slides) are Tier 3-4 and the terminology itself is contested among them ("one paper argues a compensation is conceptually backward recovery... another suggests backward error recovery as a particular form of forward recovery"); needs a primary textbook source (e.g., Gray & Reuter, Transaction Processing: Concepts and Techniques) before this can anchor a claim. [unverified-mechanism — needs primary]
• Dan Tsafrir, Tomer Hertz, David Wagner, Dilma Da Silva, "Portably Solving File TOCTTOU Races with Hardness Amplification" (USENIX FAST 2008) is cited directly in CWE-367's own references [REF-367] as prior TOCTOU-mitigation research — not yet read, but a primary candidate for a deeper mitigation-techniques note.
• "On the TOCTOU Problem in Remote Attestation" (arXiv, surfaced by search but not fetched this session) discusses TOCTOU mitigation in a specialized remote-attestation context (randomized block-order schemes like SMARM) — a different sub-literature from the file/database TOCTOU this capture covered.
• CWE-367's "Research Gap" note states plainly: "Non-symlink TOCTOU issues are not reported frequently, but they are likely to occur in code that attempts to be secure" — worth flagging as a standing gap given the vault's own kernel-timer and (per this capture) agent-tooling instances are both non-symlink TOCTOU.
• A 2024 arXiv preprint, "Systematic definition and classification of data anomalies in DBMS," surfaced by search — not read — could be a stronger primary source than the existing Berenson 1995 paper for how modern database theory classifies lost-update-adjacent anomalies; worth a follow-up fetch.

Entity candidates

• H.T. Kung — person — co-author of the 1981 optimistic-concurrency-control paper; the field's foundational figure for "optimistic locking," and the one this whole tradition's priority rests on (ask-first per the known blind spot: the ancestor, not the citing paper).
• John T. Robinson — person — co-author of the same 1981 paper; equal billing with Kung on the OCC foundation.
• MITRE Corporation / CWE — concept/org — maintains the CWE-362/367 taxonomy that is the closest thing to an authoritative "standard fix" registry for this failure shape; already load-bearing for claim-cve-2025-38352-timer-sweep-toctou, now load-bearing here too.
• Optimistic concurrency control (OCC) — concept — the formal name behind "optimistic locking"; distinct from, but routinely conflated with, TOCTOU mitigation.
• Forward recovery / backward recovery — concept — contested fault-tolerant-systems vocabulary that may be the more precise academic category for "revert forward and flag it" than OCC is; flagged above as needing a primary source.