2026.10.54 — 2026-10-20

Breaking

• Publish to Maven Central only when a maintainer runs it (dadfe541)

  Maven Central limits how much a namespace publishes, so a release no longer goes there on its own. A maintainer publishes a release with the new "Publish to Maven Central" workflow (gh workflow run publish-central.yml -f version=YYYY.MM.N): one run publishes that release's plugin API, when the backend changed since the newest version on Central, and its Java client. Docker Hub, the GitHub release and npm still get every release (ADR-0205).

• Store a cluster's broker accounts by plane (fef3a500)

  A cluster's stored broker accounts are named for what they reach, MANAGEMENT and DATA, instead of the Artemis protocols JOLOKIA_BASIC and CORE.

• Name the setup review tables after Artemis (89ef9359)

  Setup review exists for Artemis only, so its tables carry the system's prefix: artemis_setup_review, artemis_setup_finding and artemis_setup_finding_acceptance. The MCP tool and the REST endpoints keep their names.

• Prefix the broker configuration tables with artemis_ (0816fc01)

  Broker configuration manages Artemis's broker.xml only, so its tables carry the system's prefix: artemis_config_revision, artemis_config_declaration, artemis_config_apply, artemis_config_node_state and artemis_config_owned_item.

• Name governance rules and findings by destination (d1425d05)

  Classification findings record the destination a value was seen on, and a governance rule scopes itself by destination_pattern.

• Record transfer runs in broker-neutral terms (deef7a05)

  A transfer run records its source and target subscription, destination, native_node_id, and what the system says beyond that in native_attributes (an Artemis queue's routing type).

• Keep request-reply expectations and flows in neutral terms (52b164ef)

  An expectation names its request_destination and reply_destinations; a flow its request_destination. A flow's reply kind is TEMPORARY (a short-lived reply destination per requester) or SHARED (one reply destination, correlated by id).

• Keep flow samples, bulk items and plugin registrations in neutral terms (56da378d)

  Flow client edges record the destination and subscription a client produces to or consumes from. A sampled route records its broker SDK route_class (binding, forward or link) beside its native_kind. Bulk run items and plugin message registrations name their subscription.

• Name the message index's columns in broker-neutral terms (33460526)

  message_index records the subscription a message was read from, its destination and, for a captured copy, its orig_destination; a capture names what it watches by subscription_pattern. The SQL console's own column names are unchanged.

• Keep the scrape cache in broker-neutral terms (022d2869)

  The scrape cache table is subscription_snapshot: a row per subscription and node, with its destination, the broker SDK kind, the standard metric columns (backlog, consumer_count, in_flight, scheduled, enqueued, acknowledged, expired) and what the system says beyond them in native_attributes (an Artemis queue's routing type). metric_sample names its subject by subject_kind and subject_path; a plugin's own metrics are kept under the kind rahdar.plugin.

• Store clusters and nodes in broker-neutral terms (4f7726ab)

  A cluster records the broker system it runs (cluster.system), and Rahdar connects to each cluster through that system's driver. A node's addresses move to their own table, broker_node_endpoint: one row per plane (management or data) and protocol, with where the address came from (seed, derived, discovered or set by an operator). A node's broker id is native_node_id, its HA pairing ha_group, and its configured role ha_designation, one of PRIMARY, BACKUP or NONE.

  Data URLs are stored ready to dial: a connector the broker advertises as host:port is kept as tcp://host:port. The approval page for a node override names the data URL as such.

• Record and query metrics under the broker SDK's standard keys (cd9a0cd6)

  Metric history, alert rules, the triage verdicts, the flow map, the REST metrics endpoint, the MCP metric_series tool and the metrics screens now use the standard metric keys:

  Before	Now
  messageCount	openbroker.backlog
  consumerCount	openbroker.consumer.count
  deliveringCount	openbroker.in_flight
  scheduledCount	openbroker.scheduled
  messagesAdded	openbroker.enqueued
  messagesAcked	openbroker.acknowledged
  messagesExpired	openbroker.expired

  The alert rule form labels each key with what it measures.

• Relay messages between brokers through the broker SDK (75b29de9)

  A transfer's relay now runs on the broker SDK's transport: a receiver on the source and a transacted sender on the target, each on its own session. The guarantees are unchanged: the target commits before the source acknowledges, a batch repeated after Rahdar stopped between the two commits is refused as a duplicate and settled one message at a time, and a large body is spooled to an owner-only file, after checking the disk has room, rather than piped between the two sessions. A copy's frozen selection is now the transport's own bound on production time.

  The Core connection pool, Rahdar's own Core connection factory and its TLS context factory are gone: every Core connection, with the cluster's TLS bundle, is the SDK's. Large-message spool files live under ${java.io.tmpdir}/rahdar-spool and are swept at startup.

• Take broker events from the broker SDK in its standard terms (1e56b66c)

  Rahdar's notification streams now come from the broker SDK: one stream per serving node, which the SDK reconnects with backoff and which says, as a gap, when it may have missed something. Events arrive in the SDK's standard terms, so the event history, the live events topic, request- reply tracing and consumer triage read the same types from every broker.

  • Event types are the SDK's: openbroker.consumer.attached, openbroker.consumer.detached, openbroker.consumer.slow, openbroker.resource.created, openbroker.resource.deleted, openbroker.client.connected, openbroker.client.disconnected, openbroker.channel.opened, openbroker.channel.closed, openbroker.message.delivered and openbroker.message.expired. Anything else a broker reports keeps its own namespaced type, such as artemis.<type>.
  • An event's properties are the SDK's data: the standard keys (openbroker.destination, openbroker.subscription, …) and the broker's own, namespaced (artemis._AMQ_NotifType).
  • The events page filters by the standard types, with readable names.
  • Registering a cluster, or editing its connection, checks the Core account and the notification permission with one subscription per node rather than two separate checks.
  • Removing a cluster now also closes its broker connection; it stayed open until a restart.

• Read, send and drain messages through the broker SDK (d10fbc35)

  Browsing, sending, counting and acting on messages, the SQL console and its tails, the request-reply sampler, message capture and plugin message delivery now go through the broker SDK. The SDK's driver chooses the channel: for Artemis it reads the first window of a queue over the Core client, a deeper page or a node without a reachable Core endpoint over Jolokia, and a send whose Core endpoint cannot be reached goes over Jolokia instead of failing.

  • Message capture drains each capture queue through a transacted receiver on its own virtual thread and commits a batch only after its rows are stored, so the guarantee is unchanged: store first, acknowledge second.
  • Plugin message delivery runs each unit of a registration's concurrency on its own virtual thread with no prefetch, so a plugin that blocks holds only its own slot.
  • A retry by message ids from a caller who may not send on the whole cluster still retries only the messages that came from the addresses they were checked against.

• List clients and close them in the broker SDK's terms (d8bfaef0)

  The address, consumer, session, connection and producer views and the connection controls now read and act through the SDK's neutral resources and operations, one batched request per node, with each lookup filtered on the broker.

  • Addresses show how they deliver (point to point, publish-subscribe, or both) in a Delivery column instead of Artemis routing types.
  • Consumers show the messages in flight to them instead of Artemis's own status string, which said "OK" for nearly every consumer.
  • Producers show their client id instead of Artemis's internal producer name.
  • Creation times are ISO-8601 instants.

• Reach every broker through the OpenBroker SDK (69c941e2)

  Rahdar no longer has a Jolokia client of its own. Every management call goes through the OpenBroker SDK's Artemis driver, admitted by the same per-node rate limiter, call guard, clock-offset reading and Micrometer observations as before. The requests a broker receives are the same, with three deliberate differences:

  • Registering a cluster reads the seed node's HA attributes and version in the one request that used to read the version alone.
  • Checking a node's management URL override reads its HA attributes after the search that resolves its broker.
  • Core over TLS verifies the broker's host name unless the cluster's connection settings turn verification off.

  What only Artemis has (its message transports, staging queues, broker commands, the capability probe and queue location) is now the system.artemis module, the one place that reaches the driver's Artemis extension.

Added

• Store clusters and nodes in broker-neutral terms (4f7726ab)

  A cluster records the broker system it runs (cluster.system), and Rahdar connects to each cluster through that system's driver. A node's addresses move to their own table, broker_node_endpoint: one row per plane (management or data) and protocol, with where the address came from (seed, derived, discovered or set by an operator). A node's broker id is native_node_id, its HA pairing ha_group, and its configured role ha_designation, one of PRIMARY, BACKUP or NONE.

  Data URLs are stored ready to dial: a connector the broker advertises as host:port is kept as tcp://host:port. The approval page for a node override names the data URL as such.

• Record and query metrics under the broker SDK's standard keys (cd9a0cd6)

  Metric history, alert rules, the triage verdicts, the flow map, the REST metrics endpoint, the MCP metric_series tool and the metrics screens now use the standard metric keys:

  Before	Now
  messageCount	openbroker.backlog
  consumerCount	openbroker.consumer.count
  deliveringCount	openbroker.in_flight
  scheduledCount	openbroker.scheduled
  messagesAdded	openbroker.enqueued
  messagesAcked	openbroker.acknowledged
  messagesExpired	openbroker.expired

  The alert rule form labels each key with what it measures.

• Refuse plugin packages under the broker SDK or a driver's client (f01f71ca)

  A plugin's base package may no longer sit under io.github.sudoitir.openbroker or under the client libraries an installed broker driver brings (for Artemis, org.apache.activemq and org.jolokia). The reserved list is read from the installed drivers, so a new driver reserves its own client packages.

• Take broker events from the broker SDK in its standard terms (1e56b66c)

  Rahdar's notification streams now come from the broker SDK: one stream per serving node, which the SDK reconnects with backoff and which says, as a gap, when it may have missed something. Events arrive in the SDK's standard terms, so the event history, the live events topic, request- reply tracing and consumer triage read the same types from every broker.

  • Event types are the SDK's: openbroker.consumer.attached, openbroker.consumer.detached, openbroker.consumer.slow, openbroker.resource.created, openbroker.resource.deleted, openbroker.client.connected, openbroker.client.disconnected, openbroker.channel.opened, openbroker.channel.closed, openbroker.message.delivered and openbroker.message.expired. Anything else a broker reports keeps its own namespaced type, such as artemis.<type>.
  • An event's properties are the SDK's data: the standard keys (openbroker.destination, openbroker.subscription, …) and the broker's own, namespaced (artemis._AMQ_NotifType).
  • The events page filters by the standard types, with readable names.
  • Registering a cluster, or editing its connection, checks the Core account and the notification permission with one subscription per node rather than two separate checks.
  • Removing a cluster now also closes its broker connection; it stayed open until a restart.

• Read, send and drain messages through the broker SDK (d10fbc35)

  Browsing, sending, counting and acting on messages, the SQL console and its tails, the request-reply sampler, message capture and plugin message delivery now go through the broker SDK. The SDK's driver chooses the channel: for Artemis it reads the first window of a queue over the Core client, a deeper page or a node without a reachable Core endpoint over Jolokia, and a send whose Core endpoint cannot be reached goes over Jolokia instead of failing.

  • Message capture drains each capture queue through a transacted receiver on its own virtual thread and commits a batch only after its rows are stored, so the guarantee is unchanged: store first, acknowledge second.
  • Plugin message delivery runs each unit of a registration's concurrency on its own virtual thread with no prefetch, so a plugin that blocks holds only its own slot.
  • A retry by message ids from a caller who may not send on the whole cluster still retries only the messages that came from the addresses they were checked against.

• List clients and close them in the broker SDK's terms (d8bfaef0)

  The address, consumer, session, connection and producer views and the connection controls now read and act through the SDK's neutral resources and operations, one batched request per node, with each lookup filtered on the broker.

  • Addresses show how they deliver (point to point, publish-subscribe, or both) in a Delivery column instead of Artemis routing types.
  • Consumers show the messages in flight to them instead of Artemis's own status string, which said "OK" for nearly every consumer.
  • Producers show their client id instead of Artemis's internal producer name.
  • Creation times are ISO-8601 instants.

Fixed

• Refuse an approved queue delete when the queue was recreated (4a3f2a45)

  An approved queue delete was pinned to the address and routing type the queue was bound with, so a queue deleted and created again with the same binding after approval, or one a further node took on, was deleted under the old approval. It is now pinned to the broker's own identity of the queue across the cluster: which nodes hold it and which incarnation each holds. The run is refused when either changed; a backlog that grew still runs, since the count is an estimate for the approver.

• Refuse a filter that could escape the frozen selection (7e803747)

  A transfer selected by filter is limited to the messages that existed when it started, by composing (filter) AND AMQTimestamp <= t0. A filter that closed the parenthesis itself, such as a=1) OR (1=1, escaped that bound, so an approved transfer could also move messages produced after approval and a run against a live queue might never end.

  The filter is now parsed with the broker's selector grammar first, and a transfer whose filter is not one complete expression is refused with transfer-invalid-filter before any message moves.

Security

• Take the runtime base image with the fixed curl (a11116d6)

  The runtime image's curl and libcurl had a high-severity CVE (CVE-2026-92392) fixed in 8.18.0-1ubuntu2.8; the newer base image digest picks the fix up.

Ci

• Publish to Maven Central only when a maintainer runs it (dadfe541)

  Maven Central limits how much a namespace publishes, so a release no longer goes there on its own. A maintainer publishes a release with the new "Publish to Maven Central" workflow (gh workflow run publish-central.yml -f version=YYYY.MM.N): one run publishes that release's plugin API, when the backend changed since the newest version on Central, and its Java client. Docker Hub, the GitHub release and npm still get every release (ADR-0205).

Refactor

• Store a cluster's broker accounts by plane (fef3a500)

  A cluster's stored broker accounts are named for what they reach, MANAGEMENT and DATA, instead of the Artemis protocols JOLOKIA_BASIC and CORE.

• Name the setup review tables after Artemis (89ef9359)

  Setup review exists for Artemis only, so its tables carry the system's prefix: artemis_setup_review, artemis_setup_finding and artemis_setup_finding_acceptance. The MCP tool and the REST endpoints keep their names.

• Prefix the broker configuration tables with artemis_ (0816fc01)

  Broker configuration manages Artemis's broker.xml only, so its tables carry the system's prefix: artemis_config_revision, artemis_config_declaration, artemis_config_apply, artemis_config_node_state and artemis_config_owned_item.

• Name governance rules and findings by destination (d1425d05)

  Classification findings record the destination a value was seen on, and a governance rule scopes itself by destination_pattern.

• Record transfer runs in broker-neutral terms (deef7a05)

  A transfer run records its source and target subscription, destination, native_node_id, and what the system says beyond that in native_attributes (an Artemis queue's routing type).

• Keep request-reply expectations and flows in neutral terms (52b164ef)

  An expectation names its request_destination and reply_destinations; a flow its request_destination. A flow's reply kind is TEMPORARY (a short-lived reply destination per requester) or SHARED (one reply destination, correlated by id).

• Keep flow samples, bulk items and plugin registrations in neutral terms (56da378d)

  Flow client edges record the destination and subscription a client produces to or consumes from. A sampled route records its broker SDK route_class (binding, forward or link) beside its native_kind. Bulk run items and plugin message registrations name their subscription.

• Name the message index's columns in broker-neutral terms (33460526)

  message_index records the subscription a message was read from, its destination and, for a captured copy, its orig_destination; a capture names what it watches by subscription_pattern. The SQL console's own column names are unchanged.

• Keep the scrape cache in broker-neutral terms (022d2869)

  The scrape cache table is subscription_snapshot: a row per subscription and node, with its destination, the broker SDK kind, the standard metric columns (backlog, consumer_count, in_flight, scheduled, enqueued, acknowledged, expired) and what the system says beyond them in native_attributes (an Artemis queue's routing type). metric_sample names its subject by subject_kind and subject_path; a plugin's own metrics are kept under the kind rahdar.plugin.

• Relay messages between brokers through the broker SDK (75b29de9)

  A transfer's relay now runs on the broker SDK's transport: a receiver on the source and a transacted sender on the target, each on its own session. The guarantees are unchanged: the target commits before the source acknowledges, a batch repeated after Rahdar stopped between the two commits is refused as a duplicate and settled one message at a time, and a large body is spooled to an owner-only file, after checking the disk has room, rather than piped between the two sessions. A copy's frozen selection is now the transport's own bound on production time.

  The Core connection pool, Rahdar's own Core connection factory and its TLS context factory are gone: every Core connection, with the cluster's TLS bundle, is the SDK's. Large-message spool files live under ${java.io.tmpdir}/rahdar-spool and are swept at startup.

• Reach every broker through the OpenBroker SDK (69c941e2)

  Rahdar no longer has a Jolokia client of its own. Every management call goes through the OpenBroker SDK's Artemis driver, admitted by the same per-node rate limiter, call guard, clock-offset reading and Micrometer observations as before. The requests a broker receives are the same, with three deliberate differences:

  • Registering a cluster reads the seed node's HA attributes and version in the one request that used to read the version alone.
  • Checking a node's management URL override reads its HA attributes after the search that resolves its broker.
  • Core over TLS verifies the broker's host name unless the cluster's connection settings turn verification off.

  What only Artemis has (its message transports, staging queues, broker commands, the capability probe and queue location) is now the system.artemis module, the one place that reaches the driver's Artemis extension.