Chat Room State Held Only In Memory Does Not Survive a Cold Boot Without a Snapshot

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOS-kernellib chat-app persistence branch, a chat session held in in-memory property-bearing objects -- not written to an on-disk structured store -- does not survive a cold boot taken without loading the snapshot. The dispatch shape is: boot 1 establishes a session on a fresh room (two members, three messages, a cross-clone mention-tracker reference), records the session shape to an on-disk marker file, and dumps a snapshot; boot 2 restarts against the snapshot and confirms the session survived (the paired positive Observation); boot 3 starts DGD cold without the snapshot argument. On boot 3 the test driver's setup_and_run finds the on-disk marker present (a file, which survives any boot) but the saved-as-global persist_room nil (a cold boot resets all object globals to nil). That combination -- on-disk record present, in-image session absent -- is the signature of a session that was persisted but whose snapshot was not loaded; the driver writes COLDBOOT-LOST OK. The Observation fixes the boundary of orthogonal persistence: the runtime image survives a restore, but in-memory-only state does not survive a from-scratch boot, and durability beyond the image is the job of an on-disk store, not of in-memory properties.

Grounds

This is an Empirical Observation. The grounds are the third boot of the captured 2026-05-29 smoke run against the live MVA demonstration instance with examples/chat-app/ deployed into the isolated runtime staging tree. Boots 1 and 2 (the paired positive Observation) establish and verify snapshot survival; boot 3 exercises the cold-boot-without-snapshot loss.

Setup (verifiable from repo state):

Load-bearing source (the cold-boot detection branch in examples/chat-app/sys/test.c):

static void setup_and_run()
{
    catch(make_dir("/usr/Chat/data"));

    /* Negative-case path. Reached only on a cold boot (no snapshot
     * loaded) that follows a boot which wrote the marker in an earlier
     * phase: the on-disk marker is present, but the in-image chat
     * session it recorded is gone (persist_room is a fresh nil
     * global). */
    if (marker_present() && !persist_room) {
        coldboot_loss_verify();
        return;
    }

    catch(remove_file(RESULT_FILE));
    run_tests();
}

private void coldboot_loss_verify()
{
    string marker;

    marker = nil;
    catch { marker = read_file(MARKER_FILE); }
    if (!marker) {
        log_line("ChatApp:test: FAIL: COLDBOOT-LOST marker unreadable");
        return;
    }
    if (persist_room) {
        log_line("ChatApp:test: FAIL: COLDBOOT-LOST room unexpectedly present");
        return;
    }
    log_line("ChatApp:test: COLDBOOT-LOST OK");
}

The marker file (/usr/Chat/data/persist-marker.log) is written by an earlier phase just before the dump; it records the session shape (messages=3 members=2). It is an ordinary on-disk file, not in-image state, so it survives any boot independent of the snapshot. persist_room is a non-static object global; on a cold boot (no snapshot loaded) it is nil. The conjunction of marker-present and persist_room-nil is the detectable signature of "a session was persisted but the snapshot was not loaded."

Boot sequence:

# Boot 3 (cold, NO snapshot argument).
$ dgd <instance config> &
** DGD 1.7.9
** Initializing...
** Initialization complete.

Boot 3 emits ** Initialization complete. (a fresh initialization), NOT ** State restored. -- it is a cold boot, not a restore. The Chat domain's initd recompiled and re-ran from scratch; the test driver's create() fired its deferred call_out, and setup_and_run took the cold-boot-loss branch.

Smoke transcript (the full result log after all three boots):

ChatApp:test: starting
ChatApp:test: CAP-REJECT OK
ChatApp:test: CAP-ACCEPT OK
ChatApp:test: PERSIST-SETUP OK
ChatApp:test: PERSIST-VERIFY OK
ChatApp:test: COLDBOOT-LOST OK

COLDBOOT-LOST OK writes to the sentinel file only when, on boot 3:

  1. marker_present() is true (the on-disk record written by the earlier phase survived the cold boot).
  2. read_file(MARKER_FILE) returns the marker content (it is readable -- proof the session existed and its shape was recorded).
  3. persist_room is nil (the in-image room saved as a global did NOT survive the cold boot).

The third assertion is the load-bearing one: a non-nil persist_room here would be a contradiction (it would mean the snapshot was loaded, in which case this branch would not have been taken). The driver does NOT wipe the result file on this path, so the boot-1 and boot-2 sentinels remain and the transcript reads as a single coherent record across all three boots.

What the evidence establishes:

What the evidence does not establish:

What Would Revise It

Sources

Relations