Queues & streams
Publish, inspect and drain messages on a deployed broker.
eqs mq works against a broker you deployed from the marketplace. Same envelope as eqs db — the api holds the credentials, checks the permission and records what ran — and deliberately different verbs, because a queue has no rows to select.
What the broker holds. NATS streams; refused on AMQP, which cannot list.
eqs mq queues eventsRead messages without consuming them — as far as the broker allows.
eqs mq peek orders dead-letter --limit 5
Take messages off. They do not come back.
eqs mq consume orders dead-letter --limit 10 --json > drained.json
Put one message on a queue or subject.
eqs mq publish events orders.created '{"id":42}'Discard everything on it. Needs data.ddl.
eqs mq purge orders dead-letterA peek is not free everywhere
This is the part worth reading before you use it on production.
| Broker | What a peek does |
|---|---|
| NATS | Nothing. JetStream reads a message by sequence and leaves it exactly where it was. You can peek the same stream all day |
| AMQP | Touches it. The protocol has no look-without-taking: each message is fetched and put back, and RabbitMQ marks it redelivered |
The result always reports which of the two you got, so a script can tell.
Permissions
| Verb | Needs | Held by |
|---|---|---|
queues, peek | data.read | Reader, Contributor, Owner |
consume, publish | data.write | Contributor, Owner |
purge | data.ddl | Owner |
purge is not a schema change, so data.ddl may look like the wrong home for
it. It is the right one: that permission exists because editing a row and
dropping a table are not the same risk, and emptying a production queue is the
second kind. Contributors can drain a queue message by message with consume,
which returns what it took; they cannot discard the lot in one call.
What each broker cannot do
Both limits are answered by name rather than with an empty result, because "you have no queues" is a wrong answer and not a null one.
- AMQP cannot list queues. It is not part of the protocol — it lives in
RabbitMQ's management HTTP API, on a different port behind a different
credential. Name the queue instead:
eqs mq peek <svc> <queue>. - NATS needs JetStream for everything but
publish. Core NATS stores nothing: a message with no subscriber is gone, so there is nothing to peek, drain or purge.
The record
Every operation is recorded: who ran it, against which broker, which queue, and
how long it took. Message bodies are not, on the same terms as --param values
in eqs db — they are the content most likely to carry personal data.