Files

T

SluijsensandClaude Sonnet 5 0447993181 Completes local-dev-master-slave-setup: dual-instance frontend tooling, module-capability gating, and master/slave protocol self-healing fixes

Frontend (Unit 2 completion): dual dev-server tooling (pnpm dev:slave,
pnpm dev:all), per-instance browser tab titles, and a backend
capability check (SystemController + useSystemCapabilities +
ModuleGuard) so a Master-only page is hidden on a slave instance
instead of assuming every backend has every module.

Master/slave protocol fixes surfaced by actually running master and
slave side by side locally:
- Deactivating a CMS instance (Inactive) now releases the slave's
  master gate instead of leaving it stuck on its last pushed status.
- The periodic integrity check now also re-pushes status to every
  reachable slave (previously URL-verification only) and runs once
  immediately on startup.
- Added the originally-specified (but never implemented) slave-pull
  path: a slave now periodically polls its own status from the master
  (GET /api/v1/SlaveStatus) and fails open to Available if the master
  is unreachable for too long, complementing the existing push.
- The slave's own Settings page can no longer "successfully" change
  local availability while the master controls it; it's now locked
  with an explanatory banner and the backend rejects the write with
  409 instead of silently no-op'ing it.
- CMS instance status badges now match the dashboard's color/icon
  styling instead of a plain grey badge.

Also corrected the master-cms-module design docs to match this
as-built behavior, and flagged (without a full rewrite) a larger,
pre-existing divergence between its inception-stage application
design and what construction actually built.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-04 19:53:52 +02:00

4.0 KiB

Raw Blame History

Integration Test Instructions — Local Dev Master/Slave Setup

Purpose

Verify that the two backend instances (Unit 1) and frontend tooling (Unit 2) work together correctly: the slave instance genuinely excludes the Master module, and the existing master↔slave connection mechanism (unchanged by this feature) can be exercised end-to-end using the two local instances.

Test Scenarios

Scenario 1: Module isolation — Slave excludes Master, Master keeps all modules

Description: Confirm SlpModularCms.Api.Slave's ModuleOrchestrator never discovers Modules.Master, while SlpModularCms.Api is unaffected.

Setup: None beyond a successful build (no database required — module discovery happens before any DB access).

Test Steps (already executed in this session):

dotnet run --project src/SlpModularCms.Api --launch-profile https --no-build
dotnet run --project src/SlpModularCms.Api.Slave --launch-profile https --no-build

Expected Results:

Master log output: Module ontdekt: Availability, Module ontdekt: Identity, Module ontdekt: Master, 3 modules succesvol geladen.
Slave log output: Module ontdekt: Availability, Module ontdekt: Identity, 2 modules succesvol geladen. — no Master line.

Actual Result: ✅ Passed — confirmed exactly as expected in this session's console output (see Unit 1 code generation summary).

Cleanup: Stop both processes (Ctrl+C / process termination).

Scenario 2: End-to-end master/slave connection via the existing "Add CMS Instance" flow

Description: With both instances running against separate local databases, use the master frontend's existing "Add CMS Instance" dialog to register the local slave and confirm the connection is established (per FR-4 and the runbook in root README.md).

Setup:

A local SQL Server instance reachable from both backends (e.g. via the podman run ... mcr.microsoft.com/mssql/server command in root README.md).
src/SlpModularCms.Api/appsettings.local.json (master) and src/SlpModularCms.Api.Slave/appsettings.local.json (slave, from appsettings.local.json.example) pointing at different database names on that SQL Server.
Master and slave backends running (dotnet run --project src/SlpModularCms.Api --launch-profile https and dotnet run --project src/SlpModularCms.Api.Slave --launch-profile https).
Master frontend running (pnpm dev in frontend/), logged in as an Owner.

Test Steps:

Navigate to the /cms page on the master frontend.
Use "Add CMS Instance" with URL https://localhost:7222 (the local slave).
Observe the instance's status in the UI.

Expected Results: The instance appears in the list and its status reflects a successful connection (per the existing, unchanged CmsInstanceService/SlaveApiClient ↔ MasterController protocol documented in root README.md's "Master CMS Module" section).

Actual Result: ⚠️ Not run in this session — this sandboxed environment has no accessible container runtime (docker/podman both unavailable), so no local SQL Server instance could be provisioned to run either backend past module discovery. This step requires manual execution by the developer following the runbook in root README.md ("Lokaal Master + Slave Draaien (Dev)"). Scenario 1 (module isolation, which does not require a database) was fully verified automatically and is the aspect this feature actually changes — Scenario 2 exercises the pre-existing, unmodified master/slave protocol and primarily validates that the new run configuration (ports, separate databases, CORS) doesn't get in the way of it.

Cleanup: Remove the CMS instance registration if desired; stop both backends and frontends; stop the SQL Server container if it was started solely for this test.

Notes

No automated integration test suite was added for Scenario 2 — it's an inherently manual, cross-process, cross-database verification of local developer tooling, not a candidate for CI automation (per NFR-3, this feature is explicitly local-only in scope).

4.0 KiB Raw Blame History