As per https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq, if you use the delayed exchange, and set the x-delay header, the headers when it is received by the application on the other end (also using py-amqp), the header becomes mangled as it is negated when it is sent via the delayed exchange to confirm it was delayed (see https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq#checking-if-a-message-was-delayed).
Take the following headers on a message (for example):
{'x-retries': 3, 'x-delay': 1000}
Upon receipt on the other side of RabbitMQ, py-amqp shows these as
{'x-delay': 18446744073709550616, 'x-retries': 3}
X-Delay is, indeed, -1000, if you look at it as a signed integer. It appears the library sees it as an unsigned integer and therefore produces a potentially catastrophically incorrect answer.
As per https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq, if you use the delayed exchange, and set the x-delay header, the headers when it is received by the application on the other end (also using py-amqp), the header becomes mangled as it is negated when it is sent via the delayed exchange to confirm it was delayed (see https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq#checking-if-a-message-was-delayed).
Take the following headers on a message (for example):
Upon receipt on the other side of RabbitMQ, py-amqp shows these as
X-Delay is, indeed, -1000, if you look at it as a signed integer. It appears the library sees it as an unsigned integer and therefore produces a potentially catastrophically incorrect answer.