Pre-flight Checklist
📝 Bug Description
mem_save (and every other write path) unconditionally enqueues cloud sync mutations — even when cloud is not configured, no cloud URL is set, and sync_enrolled_projects is empty. The mutations accumulate forever as dead letters in sync_mutations (with sync_state rows for cloud / cloud:{project} targets auto-created on every save).
On a machine that has never enrolled in cloud:
- May 2026: 997 dead-letter mutations had accumulated
- June 11: 3,131 more since the May cleanup
Empirically verified the targets are self-regenerating: deleted all cloud% rows from sync_state AND all rows from cloud_upgrade_state, then ran a single canary engram save — the cloud + cloud:{project} sync_state rows and 2 fresh mutations reappeared immediately. There is no local config file or env var involved (~/.engram contains only the DB; engram cloud status = not configured).
Side effects beyond disk noise:
engram doctor can flip to blocked on these dead letters (e.g. sync_mutation_required_fields when a queued payload is malformed) — alarming users about a sync pipeline they never opted into.- The queue's
entity_key set fossilizes junk project names from the past (cloud:c:, cloud:\, typo'd names), which resurface in diagnostics.
🔄 Steps to Reproduce
- Fresh engram install, never run
engram cloud enroll/config (engram cloud status → not configured)
engram save "test" "hello" --project foo- Inspect:
SELECT COUNT(*) FROM sync_mutations WHERE target_key LIKE 'cloud%'; and SELECT * FROM sync_state WHERE target_key LIKE 'cloud%';
✅ Expected Behavior
No cloud-targeted mutations are enqueued unless a cloud target is configured/enrolled. (Or at minimum: a retention cap / pruning for unenrolled targets, and doctor ignoring dead letters for targets that aren't configured.)
❌ Actual Behavior
Every save enqueues mutations toward a cloud target that doesn't exist; the queue grows without bound (~4k rows in ~5 weeks of normal use) and can put doctor into blocked.
Engram Version
engram 1.16.1 (also observed on 1.15.x)
Operating System
Windows 11
Pre-flight Checklist
status:approvedbefore a PR can be opened📝 Bug Description
mem_save(and every other write path) unconditionally enqueues cloud sync mutations — even when cloud isnot configured, no cloud URL is set, andsync_enrolled_projectsis empty. The mutations accumulate forever as dead letters insync_mutations(withsync_staterows forcloud/cloud:{project}targets auto-created on every save).On a machine that has never enrolled in cloud:
Empirically verified the targets are self-regenerating: deleted all
cloud%rows fromsync_stateAND all rows fromcloud_upgrade_state, then ran a single canaryengram save— thecloud+cloud:{project}sync_state rows and 2 fresh mutations reappeared immediately. There is no local config file or env var involved (~/.engramcontains only the DB;engram cloud status=not configured).Side effects beyond disk noise:
engram doctorcan flip toblockedon these dead letters (e.g.sync_mutation_required_fieldswhen a queued payload is malformed) — alarming users about a sync pipeline they never opted into.entity_keyset fossilizes junk project names from the past (cloud:c:,cloud:\, typo'd names), which resurface in diagnostics.🔄 Steps to Reproduce
engram cloud enroll/config(engram cloud status→not configured)engram save "test" "hello" --project fooSELECT COUNT(*) FROM sync_mutations WHERE target_key LIKE 'cloud%';andSELECT * FROM sync_state WHERE target_key LIKE 'cloud%';✅ Expected Behavior
No cloud-targeted mutations are enqueued unless a cloud target is configured/enrolled. (Or at minimum: a retention cap / pruning for unenrolled targets, and
doctorignoring dead letters for targets that aren't configured.)❌ Actual Behavior
Every save enqueues mutations toward a
cloudtarget that doesn't exist; the queue grows without bound (~4k rows in ~5 weeks of normal use) and can putdoctorintoblocked.Engram Version
engram 1.16.1 (also observed on 1.15.x)
Operating System
Windows 11