amqp: sender settlement mode "unsettled" requested, received "mixed" from server

[devigned]

In vcabbage/amqp#157 (v0.11.0) an error is thrown when the link is established if the requested settlement mode does not match the server responded settlement mode.

For the time being, consumers of this library should use https://github.com/vcabbage/amqp v0.10.2.

[vcabbage]

I'm interested in any thoughts on this. When I implemented the check I considered omitting the error when the server responds with mixed, but that didn't seem right because if the application specifically requests unsettled, mixed still allows the server to send settled messages. If the application doesn't actually care the settlement mode options can be omitted and it will accept whatever the server responds with.

I also considered adding an option that disabled the strict check, but the only use case I could think of for that would be if the server uses it as a hint but still responds with mixed and I'm not sure whether any brokers exhibit that behaviour.

[devigned]

I've talked with the team internally and here's the gist.

Does it really matter what sender-settle-mode is when receiver-settle-mode is second? Azure SB honors the receive settle mode. In fact, Azure SB supports only ‘settled’ or ‘unsettled’ for sender-settle-mode, it doesn’t support ‘mixed’.

The spec only says SHOULD, not MUST. Azure SB doesn’t explicitly set sender-settle-mode when receive-settle-mode is second. There will be a fix to Azure SB for the nil response in the scenario.

If we assume receive-settle-mode takes precedence, then send-settle-mode doesn’t matter in this case. Anyway the spec doesn’t explicitly discuss this ambiguity.

We can’t say if the client SHOULD assume that the settlement mode was accepted by the broker. But it CAN assume that safely. That’s what Azure SB .net and java clients do.

For the time being, I think I'm going to disable the strict check so that when nil is returned, the behavior is as expected.

[devigned]

@vcabbage after thinking about this a bit more, I support the strict check. It's beneficial to the consumer they are 100% clear on the settlement mode. Azure Service Bus make some assumptions about the settlement mode. In this library, I can write around those scenarios, but for the general AMQP library, it makes sense to be strict.