Add an authenticated RabbitMQ WebSocket stream gateway #60

New issue

Open

opened 2026-07-26 02:35:00 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-26 02:35:00 +00:00

(Migrated from github.com)

Goal

Expose RabbitMQ-backed StarIntel document and target events to browser clients through a server-owned streaming gateway. Browsers cannot consume AMQP 0-9-1 TCP directly.

Scope

authenticated WebSocket endpoint under /api/v1/streams
subscriptions by exchange/routing-key/dtype/dataset with server-side authorization
server-managed queue declarations and bindings; no broker credentials sent to browsers
delivery IDs with explicit ack, nack/requeue, and reject/dead-letter commands
bounded prefetch and per-client backpressure
heartbeat, reconnect, resumable cursor/replay window, and duplicate-safe delivery metadata
JSON document/batch envelopes carrying routing key, message ID, timestamp, and schema revision
dead-letter policy and poison-message limits
metrics for active consumers, lag, settlement, redelivery, invalid payloads, and disconnects

Acceptance criteria

a Quasar client can reconnect without silently losing or infinitely replaying deliveries
filtered deliveries are settled; none remain unacked indefinitely
invalid payloads can be rejected/dead-lettered with a reason
broker credentials remain server-side
integration tests run against RabbitMQ and exercise ack/nack/reconnect/backpressure

Depends on #58. Complements #59.

## Goal Expose RabbitMQ-backed StarIntel document and target events to browser clients through a server-owned streaming gateway. Browsers cannot consume AMQP 0-9-1 TCP directly. ## Scope - authenticated WebSocket endpoint under `/api/v1/streams` - subscriptions by exchange/routing-key/dtype/dataset with server-side authorization - server-managed queue declarations and bindings; no broker credentials sent to browsers - delivery IDs with explicit `ack`, `nack/requeue`, and `reject/dead-letter` commands - bounded prefetch and per-client backpressure - heartbeat, reconnect, resumable cursor/replay window, and duplicate-safe delivery metadata - JSON document/batch envelopes carrying routing key, message ID, timestamp, and schema revision - dead-letter policy and poison-message limits - metrics for active consumers, lag, settlement, redelivery, invalid payloads, and disconnects ## Acceptance criteria - a Quasar client can reconnect without silently losing or infinitely replaying deliveries - filtered deliveries are settled; none remain unacked indefinitely - invalid payloads can be rejected/dead-lettered with a reason - broker credentials remain server-side - integration tests run against RabbitMQ and exercise ack/nack/reconnect/backpressure Depends on #58. Complements #59.