docs: arch-review remediation — component docs sweep, execution log, residuals register
Final consistency sweep per plan §6: verified component docs against shipped WP1-WP3 + adversarial-review-fix state, corrected drift found in SiteRuntime (recursion-exempt run cap, stale ScriptExecutionActor/AlarmExecutionActor references), TemplateEngine (BundleImporter watermark path), DeploymentManager (phase-2 PendingDeployment staging), CentralUI (shared KPI cache, dedup'd alarm poll, render coalescing), StoreAndForward (rate-limited drop logging), and ConfigurationDatabase (documented DbContext-pooling non-adoption). Updated the docs/components/ developer-reference set (SiteRuntime, SiteEventLogging, InboundAPI) to drop the deleted per-run actor classes. Amended one known-issue for the superseding MaxBatchSize:64 read-page pin. Added CLAUDE.md bullets for stream graceful-completion reconnect, the required site audit DB path, honest CLI HTTP timeouts, bulk DeploySiteAsync, and LocalDb 0.2.1. New execution log records the phase→commit map, gate results, adversarial-review tally, the three test-flake root causes, and the nine-item residuals register.
This commit is contained in:
@@ -30,9 +30,20 @@ case). See the Phase 2 plan (D6) and `docs/plans/2026-07-19-localdb-phase2-live-
|
||||
**Closed by LocalDb 0.2.0** (arch-review WP3.3): batching is now bounded by
|
||||
`LocalDb:Replication:MaxBatchBytes` — summed serialized bytes, default **2 MB**, sized under the
|
||||
4 MB limit — with the row count demoted to a secondary cap, and a single row above the budget sent
|
||||
alone rather than stalling the stream. The rig's `MaxBatchSize = 16` pin is retired and both keys
|
||||
are left at their defaults; a deployment replicating wide rows no longer has to size a row count
|
||||
against its widest column by hand.
|
||||
alone rather than stalling the stream. The rig's old `MaxBatchSize = 16` pin (sized against the
|
||||
4 MB *wire* limit) is retired.
|
||||
|
||||
**Amended (2026-08-14) — `MaxBatchSize` is back, pinned to a different value for a different
|
||||
reason.** `MaxBatchBytes` bounds the wire message, but it doesn't bound the DB **read page**:
|
||||
`OplogStore.ReadBatchAboveAsync`/`SnapshotStreamer` materializes a whole `MaxBatchSize`-row page
|
||||
into memory *before* the byte-budget split runs, so an unset (500-default) `MaxBatchSize` still
|
||||
lets a reconnect drain transiently allocate ~35 MB per read even though every wire message stays
|
||||
under `MaxBatchBytes` (arch-review adversarial finding F2). Both site-a nodes on `docker/` now pin
|
||||
an explicit `"MaxBatchSize": 64` to bound that transient read-side allocation, while
|
||||
`MaxBatchBytes` is left at its 2 MB default to bound the wire message; site-b/site-c stay
|
||||
unreplicated so the key doesn't apply there. Not to be confused with LocalDb 0.2.1's unrelated
|
||||
sync-inbox bound (also 64, but message count on the *receive* side, hardcoded in the library, not
|
||||
a config key) — see CLAUDE.md's LocalDb bullet.
|
||||
|
||||
Note the failure mode differs from the one documented below: an oversized gRPC message is
|
||||
**rejected**, not silently dropped.
|
||||
|
||||
Reference in New Issue
Block a user