#246) (#247) ## Summary - Add `FailedMount { name, source_dir, reason }` struct and `failed_tenants: Vec<FailedMount>` field to `TenantManager`, with `record_mount_failure()` (called by the startup loop) and `failed_tenants()` (queryable accessor) - Fix `mount()` to return `EngineError::SourceDirNotFound` instead of `InvalidTenantName` when source_dir is missing; update the error display to `source_dir "{path}" does not exist` — this is the reason string that flows into both the WARN log and `FailedMount.reason` - Update `serve.rs` startup loop to emit `[WARN] tenant "{name}" skipped: {reason}` and record each failure on the manager ## Observed behavior (reproduction step) Contrary to the issue title, a warning **was** already emitted at startup — `serve.rs` had an `eprintln!` in the `Err` path. The format was `Warning: skipping "kastrup": invalid tenant name 'kastrup': source directory does not exist: /tmp/kastrup-kb` — misleading (says "invalid tenant name" for a path problem) and not grep-stable. The real gap was no durable record on `TenantManager`, so nothing could surface the failure later. ## Follow-up issues (out of scope for this PR) - `GET /v1/tenants?include=failed` endpoint → tracked in #248 - `/readyz` extension to include `"failed": <n>` count → tracked in #249 - `pramana config list` broken-tenant marker → tracked in #250 - `pramana doctor` WARN for daemon-skipped tenants → tracked in #251 - `POST /v1/reload/:name` retry-on-failed promotion → tracked in #252 ## Test plan - [x] `cargo fmt --check` passes - [x] `cargo clippy --workspace --all-targets -- -D warnings` passes - [x] `cargo test --workspace` passes - [x] `failed_tenants_recorded_on_missing_source_dir`: mount with non-existent path returns `Err`, caller records via `record_mount_failure()`, `failed_tenants()` returns the entry with `reason` containing "does not exist" - [x] `failed_tenants_independent_from_live_tenants`: one good + one bad tenant → `tenant_count() == 1`, `failed_tenants().len() == 1` ## Notes `record_mount_failure()` is intentionally a separate call (not inside `mount()`) so `mount()` stays a pure fallible operation and callers can decide whether to record a failure or just propagate the error. Closes #246 --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Uh oh!

feat(engine): extend /readyz with failed tenant count #249

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions