muster release v5.19.7
Fixed
- A suspended MCPServer is not started when muster boots (#1216). The orchestrator’s boot pass created and started a service for every definition with
autoStart: true without looking at spec.suspended (what core_service_stop and a portal’s Deactivate write), and the reconciler’s first pass then stopped it again: per restart and per suspended server one Creating MCPServer service / Starting MCP server service / Suspending MCPServer service <name> (spec.suspended=true) sequence in the log, one connection attempt against a backend the operator had switched off, a MCPServerStarting and a MCPServerStopped event, status.lastAttempt moved to the boot time, and – when the connect won the race against the stop – a window in which the deactivated server’s tools were registered in the aggregator and callable. The boot pass now skips a suspended definition the way it skips autoStart: false (Skipping MCPServer <name>: Suspended=true at debug level); the server keeps reading Disconnected (stdio: Stopped) through the reconciler’s no-service branch, its status keeps its pre-restart lastAttempt, and spec.suspended: false still starts it. muster test: a pre-configured mock server accepts suspended: true, which also takes it out of the readiness gate. Scenario: mcpserver-suspended-not-started-at-boot.