Skip to content

vault: read-only opens for inspect/list commands while a daemon holds the writer #533

@kwsantiago

Description

@kwsantiago

Follow-up to #422 part (b). Part (c) (clearer error message) shipped in PR #534.

Correction to the original framing

The original body said "redb supports concurrent read-only opens alongside a writer" — that's NOT true. Database::open acquires an exclusive file lock; the second_open_surfaces_lock_holder_hint test in PR #534 directly demonstrates this. The "add a read_only: bool parameter to Keep::open that routes to Database::begin_read" plan does not work because the lock is at file-open time, not at transaction time.

Revised approach

The real fix for "inspect commands coexist with a running daemon" is one of:

  1. IPC daemon (the long-term vault: single-process file lock blocks operator commands while daemon runs #422 (a) plan): the daemon owns the writer, CLI inspect commands route through a local Unix socket. Bible-correct; substantial work (protocol design, auth, hot-reload semantics).
  2. Snapshot-based read views: the daemon periodically dumps the inspectable subset (descriptors, share metadata, audit entries) to a separate read-only file the CLI consumes. Simpler than IPC but requires keeping the snapshot fresh and adds a second source of truth.
  3. Hand off the writer to the CLI command, then re-acquire: the daemon listens on a signal, releases its writer transiently to let the CLI in, then reopens. Race-prone, not recommended.

(1) is the proper architecture target; (2) might be a pragmatic shortcut for high-value read paths. (3) is on the table only as a stopgap if neither (1) nor (2) is ready.

Acceptance

  • Decision recorded between (1) and (2).
  • If (1): wire protocol + first command (e.g. keep list) over the socket.
  • If (2): snapshot file format + writer flush cadence + first reader.
  • Tests demonstrating an inspect command completes while a daemon holds the writer.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions