[Maelstromeous]

⚠️ Manual step: replace the queue on the box, then merge both PRs straight away

RabbitMQ won't change an existing queue's arguments, so the durable, lazy api-queue-production has to be swapped for a memory-only one once. Run this just before merging this PR and ps2alerts/aggregator#1025:

docker exec rabbit rabbitmqctl delete_queue --if-empty api-queue-production && \
docker exec rabbit rabbitmqctl eval 'rabbit_amqqueue:declare(rabbit_misc:r(<<"/">>, queue, <<"api-queue-production">>), false, false, [{<<"x-message-ttl">>, long, 10800000}], none, <<"rmq-cli">>).'
docker exec rabbit rabbitmqctl -q list_queues name durable arguments messages | grep '^api-queue-production\s'
# expect: api-queue-production  false  [{"x-message-ttl",10800000}]  ...

• --if-empty refuses while messages are waiting and deletes nothing. It normally sits at about 0, so re-run it a moment later.
• Assumes the default vhost /. Add -p <vhost> to both commands (and put the vhost in place of <<"/">>) if production uses another one.
• Skip it and the deploy breaks. The new declaration is refused with PRECONDITION_FAILED - inequivalent arg 'durable', so the new aggregator's API publisher can't connect inside its 5 s boot timeout, and the new api-aggregator can't consume.
• Between the command and the api deploy, nothing consumes the queue, because the delete cancels the old api consumer. Messages wait in memory (3 h TTL) and the old aggregators keep publishing into the new queue without trouble. An old container that reconnects before its own deploy is refused, so merge both PRs promptly.

Rehearsed on a local bitnamilegacy/rabbitmq:3.10.13 holding the production queue arguments. --if-empty refused while 5 messages were waiting, the delete and redeclare left 1,000 delay messages untouched, and both new declarations were then accepted. The old api declaration was refused.

What this does

This declares api-queue-production non-durable with no lazy mode, so RabbitMQ 3.10 stops writing every message to disk. It pairs with ps2alerts/aggregator#1025, which declares the queue the same way and publishes to it transient. The declarations must match, or whichever service declares second is refused with PRECONDITION_FAILED.

• rabbitmq.queueOptions is now {durable: false, messageTtl: 10800000}. The consumer and the healthcheck client both declare with it.
• A spec pins those options. It failed against main's config and passes with this change.

After any RabbitMQ restart, the queue doesn't exist until the aggregator or the api declares it again. Delay messages that expire before then are dropped. That trade-off is accepted, and ps2alerts/aggregator#1025 has the detail.

Validation done

• yarn run lint shows 0 errors; its 11 warnings are all in untouched files.
• yarn test passes 6 of 6, and yarn run build passes.
• On a local bitnamilegacy/rabbitmq:3.10.13, the built config's declaration was accepted against the redeclared queue.

🤖 Generated with Claude Code