SluijsensandClaude Sonnet 5
0447993181
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>
53 lines
4.0 KiB
Markdown
53 lines
4.0 KiB
Markdown
# 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):
|
|
```powershell
|
|
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**:
|
|
1. 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`).
|
|
2. `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.
|
|
3. 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`).
|
|
4. Master frontend running (`pnpm dev` in `frontend/`), logged in as an Owner.
|
|
|
|
**Test Steps**:
|
|
1. Navigate to the `/cms` page on the master frontend.
|
|
2. Use "Add CMS Instance" with URL `https://localhost:7222` (the local slave).
|
|
3. 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).
|