2026.09.34 — 2026-09-22

Added

• Move and copy messages from the messages screen (e73c60d5)

  The Messages screen gains "Transfer…" and "Redistribute to node…" beside its selection: pick a target cluster, node and queue, and Studio previews the run before anything moves. The preview states the blast radius in one sentence, lists what the target can and cannot accept — refused, needs acknowledgement, or could not be checked — with the broker.xml that would fix each, and arms a move only once the source queue's name is typed.

  A new Transfers view lists every run where the cluster is the source or the target, and a run's own page shows the pipeline (selected → held in staging → delivered), the state as a sentence in a live region, both nodes' outcomes, and Stop, Resume and Return to source. Staging left behind by a run Studio no longer has is listed, with a return action, so nothing strands silently.

• Move and copy messages between brokers over the API (c1ec51a2)

  Adds the transfer module's backend (ADR-0097). An operator can now move or copy messages from a queue on one node to a queue on another node, in the same cluster or another registered cluster. The screens follow in a later commit; this one adds the API under /api/v1/clusters/{clusterId}/transfers.

  • Preview (POST /preview) reads only: no staging queue is created and no message is touched. It freezes the selection at now, estimates its count and size, and checks the target. A refusal is anything that would drop messages silently or that the target cannot hold: a DROP full or page-full policy, a filtered queue, a ring queue smaller than the selection, too little room under FAIL or BLOCK, a full disk, a node that is not live or is a backup or in split-brain, or a missing queue the broker will not create. Softer risks are warnings to acknowledge. A check that could not be made is stated as unknown, never as a pass.
  • Execute needs the previewed plan, unexpired, every warning acknowledged, the source queue's name typed for a move, and the bulk-cap override over the cap. It is audited on both clusters (message.transfer and a linked message.transfer.in) and checks message:move (move) or message:read (copy) on the source and message:send on the target. A target cluster the operator cannot send to answers as not found.
  • A move between two nodes parks at most twice a batch in a studio.transfer.<runId> queue on the source broker and relays from there. A move on one node is done by the broker. A copy browses the source and records what it copied. Every batch re-checks the grants and the target's room; a full target makes the run wait and continue by itself, and stop after transfer.capacity-wait.
  • Runs can be stopped, resumed, and (a move) returned to the source. A run cut off by a Studio restart becomes interrupted and resumable. A staging queue whose run is gone is listed under /orphans and can be returned.
  • New settings: transfer.batch-size (200), transfer.messages-per-second (1000), transfer.max-concurrent-runs (4), transfer.capacity-threshold-percent (90), transfer.capacity-wait (10m).
  • New tables transfer_run and transfer_copied, applied on startup.

  A move between nodes needs Studio's broker user to hold createAddress, deleteAddress, createDurableQueue, deleteDurableQueue, send, consume and browse on studio.transfer.#. Without them the run fails before moving anything and shows the security-setting snippet.

Fixed

• Dial a broker whose Core URL has no scheme (7fa18621)

  A cross-broker move failed with "Schema <host> not found" and left its messages held in staging: discovery stores a broker-advertised connector as a bare host:port, and the relay handed that to the Core client unchanged while every other Core caller normalises it first. The relay now normalises in the one place all of its connections open, and a node with no Core URL at all is refused with a reason instead of failing inside the client.

  An affected run lost nothing — resume completes it once Studio is upgraded.

• Keep large bodies whole and never return a batch the target may hold (2970b3aa)

  The end-to-end transfer suite, run against real brokers, found four defects in the transfer feature before it shipped. Here is what each fix means for a run:

  • A large message (5 MiB in the test) arrived with only its first 20 KiB. The relay now spools each message's body as soon as it is received. Before, it spooled the whole batch after receiving it, and by then the Core consumer had cut off the earlier large bodies.
  • Returning a failed or interrupted move to its source could leave the batch that was in flight both on the target and back on the source. This happened when the target, or Studio, stopped during that batch's commit. The run now records each batch before committing it. A return first relays that batch to the target again, where its duplicate id makes it arrive exactly once, and then moves the rest back. If the target does not answer, that batch (at most one) stays in staging, and the return ends failed and says why.
  • A preview of a filter or whole-queue selection on a deep queue showed at most 200 messages, because the broker counts a filter over only management-browse-page-size messages. That low estimate let a large selection pass the safety cap unchallenged. A whole queue is now sized by its depth. A filter on a queue deeper than that page size has an unknown size: the preview says so, and the run needs the safety-cap override.
  • A move clears each message's expiration, because it takes messages off the source with the broker's own move (QueueImpl.makeCopy sets it to 0). Every other header still arrives, and a copy keeps expiration. The preview of a move now states this, and the spec and design record it.

• Trust each cluster's own TLS authority on Core connections (94c41f1f)

  Core connections now take their TLS trust from the cluster's own SSL bundle, per connection. Before, the Core client replaced the JVM-wide default TLS context with the bundle of whichever cluster connected last, so two clusters whose brokers chain to different certificate authorities could not both hold a Core connection: the second one broke the first one's trust.

  What you will notice: nothing, if all your brokers share one CA. With two or more CAs, Core browse, send, capture and notifications now work for every cluster at the same time. A cluster whose TLS reference names an SSL bundle that is not defined fails its own Core connection with the bundle named, and no other cluster is affected. Studio also no longer changes the JVM default TLS context, which other TLS clients in the process relied on.

  No configuration change is needed. Existing Core connections pick this up the next time they are opened.