2026.10.59 — 2026-10-27

Breaking

• Report a send the broker never confirmed as in doubt (b6a0e6bd)

  A send whose confirmation never came back, because the broker link was lost after the message left, is no longer reported as sent or as failed. It is in doubt: the message may or may not be on the broker, and sending it again may deliver it twice.

  • The send API answers 202 Accepted with {"inDoubt": true, "detail": …, "node": …} (InDoubtView). A client that only expected 200 should treat a 202 as "look for the message before sending it again".
  • The console's send dialog says "Not confirmed: sending a message to …" with what to check, and keeps what was typed, so a deliberate resend is one step.
  • The audit log records the send with the new outcome IN_DOUBT, shown as "in doubt" and offered as an outcome filter. Audit receivers see IN_DOUBT in AuditRecord.outcome.
  • A plugin's PluginMessaging.send throws the new MessageInDoubtException.
  • The MCP send tool answers "In doubt." with the same detail.

Added

• Report a send the broker never confirmed as in doubt (b6a0e6bd)

  A send whose confirmation never came back, because the broker link was lost after the message left, is no longer reported as sent or as failed. It is in doubt: the message may or may not be on the broker, and sending it again may deliver it twice.

  • The send API answers 202 Accepted with {"inDoubt": true, "detail": …, "node": …} (InDoubtView). A client that only expected 200 should treat a 202 as "look for the message before sending it again".
  • The console's send dialog says "Not confirmed: sending a message to …" with what to check, and keeps what was typed, so a deliberate resend is one step.
  • The audit log records the send with the new outcome IN_DOUBT, shown as "in doubt" and offered as an outcome filter. Audit receivers see IN_DOUBT in AuditRecord.outcome.
  • A plugin's PluginMessaging.send throws the new MessageInDoubtException.
  • The MCP send tool answers "In doubt." with the same detail.

• Run broker messaging on OpenBroker 0.3.0's messaging client (3fc5518e)

  Rahdar now builds on OpenBroker 0.3.0 and lets its messaging client own every broker link:

  • Plugin consumers run as the SDK's processors: one lane per unit of the registration's concurrency, one unsettled message per lane and nothing read ahead, message groups kept in order, and the broker's own delivery-attempt limit and dead-letter address. A rejected message is handed back counted and redelivered, a released one uncounted, as before.
  • A lost broker link is reopened by the SDK, on its node or on the member of its HA group now serving it, instead of stopping the plugin delivery or capture until the next reconcile pass. Messages a plugin had not acknowledged are delivered again. A capture whose commit the recovery aborted carries on; the broker redelivers what it did not take.
  • Every link's state, serving node and last cause are in the new brokerLinks health contributor (and so in the diagnostics bundle), with the most recent state changes, as the rahdar.broker.links and rahdar.broker.link.transitions metrics, and in the log.
  • A moved or copied message now always arrives durable, a non-durable one included: the relay commits on the target in a transaction, and a transaction's messages survive a broker restart.
  • Sends, receives, processing and settlements are OpenTelemetry spans and metrics in Rahdar's existing export. Rahdar never writes trace context into a message it sends, moves or relays.