2026.09.4

Breaking

• An expectation's reply address is now a set of patterns. The request-reply
  expectation API field replyAddress (a single string) is replaced by
  replyAddresses (an array of strings) on the create, update and read payloads.
  Any client posting replyAddress must send replyAddresses: ["<the old value>"]
  instead, or [] where it previously sent nothing. Stored expectations migrate
  themselves — an existing reply address becomes a one-entry set — so no operator
  action is required in the UI.

Added

• One expectation can trace reply queues you cannot list in advance. Reply
  addresses are now a set, and each entry may be a pattern: orders.reply.* covers
  a reply queue per responder, including ones created after you declared it. This is
  what makes tracing work against a deployment whose reply queue is named after the
  broker node or the client host, where any fixed list is stale as soon as something
  is redeployed. * matches any run of characters and matching is anchored at both
  ends; Artemis's # is not a wildcard here. The form shows what a pattern currently
  resolves to as you type it, and says so when it matches nothing yet — which is
  normal, not an error.

• A completed flow records which reply queue answered it. When more than one
  reply address is in play, the flow takes its reply destination from the reply that
  joined it, so you can see which responder served a given exchange.

• "Check connection" now tests the Core connection too, and registration waits for
  it. The check opened no Core connection at all, so it reported nothing about the
  channel that carries notifications and faithful message I/O — a wrong Core account, or
  the same wrong password entered twice, passed the check and only failed after the
  cluster was registered. The check now opens and closes a real subscription to
  activemq.notifications, and Register cluster stays disabled until a check of the
  exact details in the form has passed, saying which of those it is waiting for. Editing
  a URL, a username or a password invalidates the previous check rather than carrying it
  over.

• A separate broker account for the Core connection. Settings can now rotate the
  Core-protocol credentials independently of the management (Jolokia) ones. Set these
  when your management account is also the broker's <cluster-user>: Artemis reserves
  that account for inter-node traffic and refuses it over Core with AMQ229099, which
  previously left the notification subscription failing with no way to fix it short of
  re-registering the cluster.

• Pick an address instead of typing it. The request and reply address fields on the
  Requests screen now suggest the cluster's own addresses as you type, each with its
  routing type, current depth and how many nodes carry it — enough to tell a request
  queue from a reply queue without leaving the form. You can still type a name that does
  not exist yet; the field says it matched nothing rather than refusing it. The
  suggestions can be narrowed to anycast or multicast.

Changed

• The broker-capabilities notice can be dismissed. It stays dismissed for the rest of
  your session and comes back when you sign out, when someone else signs in, or when a
  different capability starts falling short — so waving away a known gap never hides a
  new one.

Fixed

• Every node serving a traced address is now sampled. Studio browsed only the
  first active node of a cluster, so in a multi-primary cluster the request and reply
  traffic on the other nodes was never read and the correlation identity that only
  browsing supplies was missing for most exchanges.

• A reply consumed faster than the sampler ticks is no longer missed. A delivery
  on a declared reply address now counts as a reply observation, alongside the
  existing browse. It carries no correlation id, so it completes a flow only where
  sampling already identified the request — coverage, not a replacement for browsing.

• Request-reply sampling failures are reported. A failure was swallowed at debug
  level, so a correctly-configured-looking expectation produced no flows and said
  nothing about why. Failures now log a warning naming the expectation and the node,
  rate-limited so a node that is down for an hour does not flood the log.

• Capabilities are assessed against a live node. Studio probed whichever node sorted
  first by name. On a cluster whose backup sorts before its primary that meant probing a
  passive backup, which registers no acceptor and no address MBeans — so Studio reported
  "CORE acceptor not found" and "activemq.notifications address not found" about a broker
  where both were present.

• A Jolokia agent that labels its JSON text/plain is understood. The agent bundled
  with Artemis 2.39 answers a valid Jolokia response with
  Content-Type: text/plain;charset=utf-8 where 2.44 sends application/json. Studio's
  client only accepted the JSON content types, so every response from the older broker
  failed to convert and a healthy cluster was reported as "the broker answered, but not
  with a Jolokia response".

• The MCP client configuration example is valid. It omitted "type": "http", which
  clients reject.

• A broker that refuses the connection now says so. Registering a cluster against an
  Artemis console that rejects the credentials reported "The broker answered, but not with
  a Jolokia response" — a message that sent operators looking for a proxy or a CORS problem
  that was not there. Studio now classifies the refusal from the HTTP status rather than
  from an exception subclass, and repeats what the broker itself said: the
  Hawtio-Forbidden-Reason header the Artemis console sets on its bare 403, and any
  WWW-Authenticate challenge.

• A management URL pointing at the console instead of the agent is named as such. Studio
  no longer follows redirects to the console's login page and then reports the resulting
  HTML as a bad Jolokia response; a redirect is reported as the wrong path, with the
  location the broker sent. A seed typed as host:port/console is completed to
  /console/jolokia rather than left to fail.

• Tracing an already-traced request address returns a conflict, not a server error.
  Adding the same request address twice failed with an HTTP 500 whose body said nothing;
  it now returns 409 naming the address, and the Requests screen shows that message. The
  enable/disable switch and the remove button on that screen also report their failures
  instead of appearing to do nothing.

• The config diff table is readable again. Long acceptor values no longer take the whole
  row and squeeze the key and status columns to one character per line; wide values scroll
  inside the section, and a key too long for its column is revealed on hover.