Files
seaweedfs/sw-block
pingqiuandClaude Opus 4.7 361f5140a4 sw-block/design: v3-recovery-wal-shipper-mini-plan + §10 P2d decision request
Adds the WalShipper implementation mini-plan that bridges
v3-recovery-wal-shipper-spec.md to the seaweed_block layout (phased
PR rollout P0..P4, INV ↔ test mapping, reviewer checklist).

§10 P2d decision request — the architect-gated handoff:

P2c is closed (slice A / B-1 / B-2 merged on g7-redo/wal-shipper-impl).
The bridging senderBacklogSink owns the live-write buffer + flushAndSeal
under sinkMu; Sender.Run barriers as soon as sink.DrainBacklog returns;
Close/closeCh/liveQueue/drainAndSeal are deleted from Sender. Atomic-seal
contract migrates intact (capture-vs-reject from queueMu → sinkMu).

P2d is gated on a three-axis decision the architect must make before a
real transport.WalShipper sink can replace the bridging path:

  1. Body format on the dual-lane port:
     (A) MsgShipEntry payload (unify on legacy steady encoding), OR
     (B) frameWALEntry payloads (teach WalShipper.Emit to encode), OR
     (C) documented third (e.g. envelope byte).

  2. Single applier owner:
     recovery.Receiver vs transport replica handler.

  3. Replay source of truth:
     which encoding the on-disk WAL playback decoder reads.

§10 also lists pre-decision deliverables that can land in parallel:
adapter scaffolding (transport-side struct satisfying recovery.WalShipperSink
by duck typing) + integration tests for architect rules 1+2 (emit context
before StartSession; restore steady lineage after EndSession).

V2 wire-compat is gated separately per feedback_porting_discipline.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 23:38:29 -07:00
..

sw-block

Private WAL V2 and standalone block-service workspace.

Purpose:

  • keep WAL V2 design/prototype work isolated from WAL V1 production code in weed/storage/blockvol
  • allow private design notes and experiments to evolve without polluting V1 delivery paths
  • keep the future standalone sw-block product structure clean enough to split into a separate repo later if needed

Suggested layout:

  • design/: shared V2 design docs
  • prototype/: code prototypes and experiments
  • .private/: private notes, phase development, roadmap, and non-public working material

Repository direction:

  • current state: sw-block/ is an isolated workspace inside seaweedfs
  • likely future state: sw-block becomes a standalone sibling repo/product
  • design and prototype structure should therefore stay product-oriented and not depend on SeaweedFS-specific paths