I'd like to understand this better.

1. Is it possible that we already had a queue for the given device_id? E.g. in case of reconnection. Does this call fail then? I suspect it's dependant on some QueueDeclareOptions
2. What happens if we publish a message (channel.basic_publish()) while the queue is not yet declared? Does the "routing key" define the queue name and when it is declared, RabbitMQ redirects it accordingly?

Is it possible that we already had a queue for the given device_id? E.g. in case of reconnection. Does this call fail then? I suspect it's dependant on some QueueDeclareOptions

It is possible. The action is idempotent, I can restart tunnelbroker, and redo the logic and it's successful the second time. The options relate to these options, since we are publishing with immediate = true, a lot of these options don't matter as they will just be deleted and kicked back to us if they fail to deliver.

What happens if we publish a message (channel.basic_publish()) while the queue is not yet declared?

I would assume that we would get an error when awaiting the confirmation. But I haven't tested this scenario.

Does the "routing key" define the queue name and when it is declared, RabbitMQ redirects it accordingly?

Rabbitmq allows some flexibility. In our case we have a simple one-to-one correlation of messages routing-key to queue names. However, amqp allows some flexibility, this post should help: https://www.cloudamqp.com/blog/part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

This was refactored out from the previous work.

Previously, the function handled all message requests, but now is scoped down to just the first message.

stream

retrieve

since we are publishing with immediate = true

@jon do you mean "since we are publishing with mandatory = true"?