How-to guide

Loop prevention for Queuey-to-Queuey delivery

When a queue delivers to another Queuey endpoint — building an event mesh across teams or tenants — you risk an event looping forever. Queuey threads a path header so it can detect and refuse loops.

The X-Queuey-Path chain

Each queue appends its own public id to X-Queuey-Path when it delivers onward, comma-separated, so every event carries the trail of queues it has passed through. Ingress stores the chain as it arrived. An event that passed through que_a and que_b, delivered onward by que_c, carries:

X-Queuey-Path
X-Queuey-Path: que_a,que_b,que_c

Two protections

  • Cycle detection — if the receiving queue's own id already appears in the incoming path, the event is refused (it would loop).
  • Hop budget — a configurable max chain length (default 8). An event arriving with more hops is refused with 422, catching misrouted topologies before they form an exact cycle.
It just works for mesh topologies
You don't configure anything per event — the path is threaded automatically on outbound delivery and checked on ingress. Raise the hop budget only when you have a documented reason; set it to 0 to disable the cap (cycle detection still runs).

Related