A Non-Atomic Cross-Agent Property Write Leaves Partial State on Error

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOSContinuum/eOS-kernellib feature/cohesive-lift branch, when the same two-room writer is run through a non-atomic batch and throws after the first write, the first room's append survives while the second room is never written. cross_write_then_fail(room_a, room_b, content) appends a message to room_a and then error()s; run through MERRY->batch(this_object(), "cross_write_then_fail", args, ([ ])) -- a plain batch with no atomic opt -- the first append commits before the throw and is not rolled back, while the second append is never reached. The room pair is left in partial state: room_a holds the message, room_b is empty. This is the failure mode the atomic batch removes by making the two writes one all-or-nothing unit; without the envelope, the error-handling and compensating writes that restore consistency are left to the application.

Grounds

This is an Empirical Observation. The grounds are a captured three-boot smoke run 2026-05-31 against the live MVA demonstration instance with examples/chat-app/ overlaid at the isolated runtime staging tree's src/usr/Chat/.

Setup (verifiable from repo state):

Driver: DGD 1.7.9 built from dworkin/dgd; binary symlinked at the isolated runtime staging tree's bin/dgd.
Kernel layer: eOSContinuum/eOS-kernellib on feature/cohesive-lift at HEAD fbda75a.
Application layer: examples/chat-app/, deployed into the isolated runtime staging tree with the Chat domain overlay.
Runtime config: the instance config; the three-boot regression harness (expected 20 sentinels).

Load-bearing source (the failing writer and phase 9d's negative half in examples/chat-app/sys/test.c):

/* appends to the first room, then throws before the second */
void cross_write_then_fail(object room_a, object room_b, string content)
{
    mapping msg;
    msg = ([ "content": content, "timestamp": time() ]);
    room_a->set_property("chat-room.message-log", room_a->query_messages() + ({ msg }));
    error("ATOMIC-ROLLBACK deliberate failure");
}

/* phase 9d negative: NON-atomic batch -- no "atomic" opt, no rollback */
MERRY_DAEMON->batch(this_object(), "cross_write_then_fail",
                    ({ room_pa, room_pb, "partial" }), ([ ]));
/* throws; asserts room_pa holds 1 (survived), room_pb holds 0 (never written) */

The non-atomic path runs the function via _run_callable rather than _atomic_run_callable, so the first set_property commits and the propagated error does not unwind it.

Smoke transcript (the load-bearing portion of the result log after boot 1):

ChatApp:test: ATOMIC-ROLLBACK OK
ChatApp:test: PARTIAL-STATE OK

PARTIAL-STATE OK writes only when the non-atomic batch threw, the first room (room_pa) holds exactly one message, and the second room (room_pb) holds zero. The assertion is inside catch{}; a non-throwing batch, a missing first write, or an unexpected second write each logs a distinct FAIL. Fresh rooms (PartialA, PartialB) make the partial write unambiguous.

What the evidence establishes:

Without the atomic envelope, a mid-operation failure leaves partial cross-object state: the first write survives, the second never lands.
The partial state is real and observable: room_pa holds the message after the throw, demonstrating the first write was not rolled back.
The atomic boundary is the difference: the same writer under an atomic batch (the paired positive) leaves no partial state; under a non-atomic batch it does.

What the evidence does not establish:

That non-atomic batching is a defect. The non-atomic path is a deliberate mode; the Observation shows the cost of choosing it for a multi-write operation, not a bug.
A general partial-state characterization. The demonstration is one failing writer over two writes; it does not characterize partial-state windows under arbitrary multi-write workloads.
Concurrent partial reads. Whether another reader observes the partial state mid-operation is not exercised; DGD's atomic-task model runs the batch to completion before any other task reads.

What Would Revise It

A non-atomic batch that rolled the first write back on the throw would falsify the partial-state claim; the current evidence shows room_pa retains its write. A change making non-atomic batches roll back on error would revise this.
A second-room write surviving the throw would contradict the never-reached claim; the current evidence shows room_pb empty.
A DGD or eOS-kernellib change to the non-atomic batch path or to property-write commit semantics would invalidate the snapshot; the claim rests on DGD 1.7.9 plus feature/cohesive-lift HEAD fbda75a.

Sources

examples/chat-app/sys/test.c (in eOS-kernellib feature/cohesive-lift) -- cross_write_then_fail and phase 9d (PARTIAL-STATE): the non-atomic partial write.
src/usr/Merry/sys/merry.c -- the batch LFUN's non-atomic _run_callable path (no rollback on error).
docs/chat-applications.md -- the "Multi-agent coherence" walkthrough, phase 9d.
The isolated runtime staging tree's src/usr/Chat/data/test-result.log -- the sentinel file; carries PARTIAL-STATE OK after a clean boot.
The three-boot regression harness and the instance config.

Relations

conforms_to::[[Observation Form Contract]]
- Carries has_epistemic_status::[[Empirical Observation]], names the measurement (one three-boot smoke run; the phase-9d partial-state assertion), states the limits (non-atomic is a deliberate mode, not a defect; one failing writer; no concurrent partial reads), and lists concrete revision conditions.
informs_downstream::[[Multiple Agents See Coherent State Without User-Land Coordination]]
- The Conviction holds that the runtime carries the coordination that keeps concurrent multi-agent state coherent. This Observation is the negative: without the atomic envelope the application is left holding partial cross-object state on error -- exactly the bookkeeping the atomic mode removes.
contrasts_with::[[An Atomic Cross-Agent Property Write Either Commits Fully or Rolls Back Fully]]
- The positive-case peer. The positive shows the atomic batch rolling both writes back on failure; this negative shows the same writer run non-atomically leaving the first room written and the second unwritten. Together they bound the mechanism: the all-or-nothing boundary is the atomic mode's contribution, and partial state is what its absence leaves behind.