Bedrock state assessment (extracted from prior Codex thread)

BEDROCK_STATE_ANALYSIS_SUMMARY.md

Bedrock State Assessment (Extracted Summary)

Source: Codex archived thread 019c5d6d-702c-7133-90b9-a88fad081eed
Date context in thread: February 14-15, 2026

Executive Summary

The thread’s conclusion was: Bedrock is architecturally promising for distributed durable state, but should be treated as pre-production for critical durability workloads until a few correctness/durability gaps are closed.

What Looked Strong

• Transaction model and conflict handling were seen as solid (Repo.transact flow).
• Control-plane/discovery architecture supports distributed coordination.
• Commit flow is designed around acknowledgements from configured logs.
• Overall shape is a good fit for Jido/Jido Signal persistence adapters.

Main Risks Identified

1. Durability contract vs implementation gap:

• Log/storage normal write paths use :file.pwrite in key paths without explicit per-append/per-advance sync.
• This creates a crash-window risk (acknowledged write vs physically durable write).

2. Unsafe defaults for HA durability:

• desired_replication_factor and desired_logs defaults are 1.
• Distributed durability is not default-safe.

3. Coordinator durability is opt-in:

• If coordinator.path is not set, coordinator Raft can be in-memory.

4. Docs/implementation mismatch:

• Parts of docs were identified as overstating sync guarantees or lagging architecture changes.

Re-Check Done in Thread (Issues/Branches)

The thread re-checked local code plus upstream items and concluded:

• The key durability concerns above were still present in main/develop at that time.
• minimum_durable_version behavior was still limited on released branches.
• feature/bedrock-as6j was recognized as a strong architectural step, but still not closing core durability correctness gaps.

feature/bedrock-as6j Assessment in Thread

Positives:

• Demux/materializer split and durability tracking direction looked good.
• Object-storage abstraction was added, enabling future non-local backends.

Remaining blockers:

• WAL append path still acknowledged around pwrite behavior in normal flow.
• Materializer normal advancement path still lacked strong immediate sync semantics.
• Risky defaults and coordinator-path caveat still existed.
• Local filesystem object-store compare-and-set semantics were flagged as not strong enough for contention-heavy correctness guarantees.

Bottom line from the thread: good direction, not yet production-ready for “very durable” claims without hardening.

Mnesia Comparison (Thread Take)

• For near-term production reliability: Mnesia was recommended as the safer choice.
• For long-term event-log-oriented architecture: Bedrock/as6j direction was considered worth investment if you are willing to own correctness hardening work first.

S3 / Long-Term Storage

• main/develop: no shipped S3 backend.
• feature/bedrock-as6j: object-storage abstraction exists, but only local filesystem backend was present in that thread.
• Conclusion: S3 looked feasible long-term by architecture, but not production-ready yet without a real backend and strong conditional-write semantics.

Suggested Author-Facing Action List

1. Make durability semantics explicit and testable (define what “durable” means at ack time).
2. Close WAL/materializer sync correctness gaps in normal write paths.
3. Raise/validate durability-safe defaults (or enforce profile checks at boot).
4. Require persistent coordinator config (or fail fast in distributed mode).
5. Align docs with actual sync/ack behavior and durability caveats.
6. Harden object-storage conditional operations before introducing S3 backend claims.