mirror of https://github.com/seaweedfs/seaweedfs.git synced 2026-08-22 15:16:56 +00:00

Files

T

pingqiuandClaude Opus 4.6 11c6aaf316 feat: Batch 7 + Phase 16C-E — command dispatch extraction + engine refinements

Batch 7: Command dispatch binding extraction
- New weed/server/blockcmd package: CommandHandler interface + DispatchCommands
- volume_server_block.go applyCoreCommandsWithAssignment delegates to dispatcher
- weed/server still owns RecordCommand, EmitCoreEvent, PublishProjection
- v2bridge NOT given command-switch or event-emission semantics

Phase 16C: Rebuilding assignment enters core command path
Phase 16D: Rebuild recovery-task startup is command-driven
Phase 16E: Catch-up recovery-task startup is command-driven

Engine refinements:
- RecoveryTarget on AssignmentDelivered event
- shouldStartRecoveryTask / shouldStartReceiver guards
- bootstrapReason: awaiting_rebuild_start

Bridge/contract updates:
- control_adapter.go: refined translation helpers
- contract.go: executor port alignment

Migration design docs (Batch 1-3 delivered, design artifacts):
- v2-first/second/third-migration-batch.md + task-pack.md
- v2-assignment-translation-unification.md
- v2-execution-muscles-inventory.md
- v2-separation-port-layer-audit.md
- v2-legacy-runtime-exit-criteria.md

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-04-04 02:13:08 -07:00

3.1 KiB

Raw Blame History

V2 Third Migration Batch

Date: 2026-04-04 Status: active

Purpose

This note defines the third migration batch for the sw-block separation work.

Batch 1 stabilized contract ownership and canonical translation. Batch 2 removed backend-binding shims and confirmed thin v2bridge implementations. Batch 3 now targets the remaining runtime-owner concentration in weed/server/block_recovery.go.

Batch Goal

Reduce weed/server/block_recovery.go to a host shell that:

owns goroutine lifecycle
owns concrete server/block-store access
delegates reusable recovery coordination to sw-block-owned helpers

Batch Scope

In scope

pending recovery execution coordination
catch-up/rebuild plan execution helper extraction
rebuild completion observation shaping
explicit isolation of legacy no-core startup behavior

Out of scope

moving the full RecoveryManager out of weed/server
changing core command semantics
removing legacy P4 or no-core paths prematurely
redesigning block-store access or sender registry ownership

Current Boundary Problem

After Batch 2, Reader, Pinner, and Executor are thinner, but weed/server/block_recovery.go still owns several reusable layers at once:

task host lifecycle
pending execution cache and mismatch cancellation
catch-up/rebuild execution helper wiring
rebuild completion shaping into core events
legacy no-core startup compatibility

That keeps too much reusable coordination trapped in the product adapter shell.

Target Package Shape

Recommended split:

keep host lifecycle in weed/server
allow reusable recovery coordination helpers in sw-block/engine/replication/runtime
keep concrete BlockVol access and server integration in weed/

Reason:

pending execution and plan completion shaping are engine-oriented, not backend-specific
those helpers should not require weed/server ownership just to exist

Concrete Batch Steps

extract pending execution coordination into reusable runtime helpers
extract catch-up/rebuild execution helper logic so weed/server only supplies IO bindings and host callbacks
extract rebuild completion observation shaping so weed/server only reads backend facts and forwards them
isolate no-core startup compatibility behind explicit legacy-only entry points

Execution Form

This batch is executed through the validate-able tasks in:

sw-block/design/v2-third-migration-task-pack.md

Why This Batch Is Third

This batch comes third because:

runtime-host thinning only becomes clear after the backend-binding layer is already reduced
otherwise block_recovery.go would still be compensating for low-level shim coupling
the remaining work is now primarily coordination extraction, not contract cleanup

Exit Condition

This batch is complete when:

weed/server/block_recovery.go is mostly host wiring and concrete backend access
reusable pending-execution and completion-shaping logic no longer requires product adapter ownership
legacy no-core startup behavior is clearly isolated as compatibility-only

3.1 KiB Raw Blame History