2026.09.12

Added

• Query messages across a cluster in SQL, with a live tail and an opt-in index (46c44883)

  The SQL Console is a new screen at Clusters → SQL Console. It answers questions
  that previously meant guessing a queue, walking pages by hand, and writing a JMS
  selector that cannot see a message body at all:

  SELECT messageId, timestamp, props.tenant, body
  FROM   "ORDER.*"
  WHERE  priority > 4 AND body->>'orderId' = '4471'
  ORDER BY timestamp DESC
  LIMIT  500
  

  What it costs a broker is stated before it runs. The EXPLAIN strip says which
  predicates the broker evaluates for free, which ones force Studio to read
  messages, and roughly how many that is — and a query over the ceiling is refused
  with the estimate and how to narrow it, rather than being run and truncated. The
  fan-out is the existing browse loop behind the existing per-node rate limiter, so
  a runaway query throttles itself against the broker.

  Every result says what it could not see. A node that did not answer is named
  rather than left out, a result that stopped at a bound says which bound, a body
  the management channel truncated is flagged because a body predicate over it can
  be a false negative, and an empty grid distinguishes "no queue matched" from "the
  queue is empty" from "a node was unreachable".

  Live tail streams matches as they arrive. It is a sample, not a capture: Studio
  re-reads the queues every few seconds, and a message that arrives and is consumed
  between two reads is never seen. The console says so permanently while tailing,
  and reports the observed gap where it can measure one. A dropped connection is
  not silently reopened — reopening would re-run an audited fan-out nobody asked
  for twice.

  The message index is off until you turn it on, per queue, in Settings → Message
  index. It keeps a copy of the messages Studio observes — headers, properties and
  bodies — so the console can still find a message the broker has already handed
  out. Because that is stored application payload, creating a subscription needs
  the settings write permission, is audited, states what it stores before it is
  confirmed, defaults to seven days' retention, and can be deleted with everything
  it captured in one action that tells you the count first. Any indexed row can be
  checked against the live broker: present, gone, or — when the read could not
  settle it — unknown, never a guess.

  Everything here is read-only. Acting on a result row goes back through the
  existing message operations, with their dry run, bulk cap and audit record.

  Requires a database migration (changeset 021), which Studio applies on startup.
  It creates the pg_trgm extension; a database user without permission to do that
  must have it created for them first:

  CREATE EXTENSION IF NOT EXISTS pg_trgm;
  

  New settings live under artemis-studio.sql: target, scan, row and timeout caps,
  the per-user concurrent query limit, the cost ceiling and the tail interval. The
  packaged defaults are deliberately conservative.