[vanrogu]

Why

A reader of the monitoring stream (the dashboard) could not tell an idle instance from a killed one. A SIGKILL'd process never reports BoundedContextStopping/Stopped, so it stayed "running" forever, even after its leases had moved to other instances. Separately, stop(), whether called in code or triggered by an operator's StopBoundedContext instruction, emitted no lifecycle event at all, so a stopped context also kept reading as running.

What

Instance heartbeat (StreamAppendingBoundedContextListener, new InstanceHeartbeat)

• Each bounded context the listener reports on gets a heartbeat. It is a bookmark holding a read position at the monitoring stream's head, re-placed every 30s. It starts at BoundedContextStarting, and terminating the context removes it.
• The interval is a new constructor argument; Duration.ZERO turns the heartbeat off.
• A bookmark, not an event: there is one row per context/logical/physical name, and every placement refreshes its updatedAt. A heartbeat event would add about a million events per instance per year.
• One virtual thread per listener places the beats, parked on a Condition between them. A beat in flight cannot put the row back after termination has removed it. A failing beat logs WARN once, and a closed store ends the beats.
• InstanceHeartbeat defines the format: reader prefix, tags, of(Bookmark) → Beat. A reader should treat a beat more than 3 intervals old as a dead process.

stop() is reported (BoundedContextImpl, BoundedContextEvent)

• stop() now emits BoundedContextStopping/Stopped with a new restartable = true; terminate() emits the same pair with false.
• A flag rather than new event types, so a reader older than this change still sees the stop. A new event type would make its typed read of the stream fail.
• Events stored before the field existed read as false (@JsonSetter(nulls = AS_EMPTY)). The existing 4-arg constructors stay and build a termination, so callers compile unchanged.
• The heartbeat keeps beating through a restartable stop, because the process is still up.

Tests

• InstanceHeartbeatTest (beat with tags at the head, refreshed while idle, removed on terminate with no beat placed afterwards, stop() keeps beating, zero interval, overdue rule)
• BoundedContextStopEventsTest (stop then start, terminate, second stop, stop then terminate, an event stored without the field)
• The full suite passes on inmem and inmem-fs. The Postgres backends were not run (no Docker where this was built). The heartbeat relies on the Postgres bookmark upsert refreshing updated_at on every placement; the SQL does that, but CI's Postgres run of InstanceHeartbeatTest is the real check.

The dashboard change that reads the heartbeat and the restartable flag is in sliceworkz/dashboard on the branch of the same name, and needs this merged and the snapshot republished first.

---

Generated by Claude Code