How delivery results leave a MailerQ node verifiedcritical

Three properties follow from using queues rather than a log or a webhook, and all three shape how Hub must behave. Destructive. A consumer takes the message. There is no cursor to rewind and no second copy, so a collector that crashes between reading and storing loses those events. Hub acknowledges each message individually after parsing it, which trades one lost event for never re-delivering thousands. Exclusive. Whoever reads is the only one who sees. A customer's application reading the same queue would split the picture invisibly between them. Either Hub is the sole consumer, or the engine is configured with separate queue names. Mandatory. Nothing prunes these queues. Not reading them is not a neutral choice: the backlog grows until the broker suffers. The trap we hit is worth recording as part of the mechanism rather than as an incident. The broker address in a node's configuration is written from the node's point of view — localhost when the broker is on the same machine — and a collector running elsewhere must translate that to the node's address before connecting. Every MailerQ node would have failed identically; there had simply never been one.