Open
Description
This is recurring question that pops up every year or two, most recently in #402.
The protocol has two types of methods:
- Synchronous: require a response, e.g.
queue.declare
- Asynchronous: don't have a response, e.g.
basic.publish
orbasic.ack
Currently continuations that hit a failure (e.g. a timeout) can't be mixed with asynchronous methods in practice. It would be nice to investigate whether that'd be possible without significant implementation changes that carry the risk of subtle concurrency semantics changes.
Specifically the following two scenarios:
* A synchronous method that fails
* An asynchronous method
* An asynchronous method that fails
* A synchronous method
Note that in practice many types of continuation failure will result in a connection recovery sequence, and thus newly opened channel(s), so a way to test this in isolation would be highly desired.
We may want to make up our mind and investigate #83, #356 first.