Document RPC failure modes of the API calls

Registered by Bogdan Dobrelya on 2015-10-26

Address all of the RPC timeout based failure modes of the API documentation in order to
keep messaging library developers and apps developers "at the same

        Typical RPC (with the message broker involved) call is:
        1) A caller (RPC client) subscribes to an exchange using
        unique key to receive a reply from RPC server
        2) The caller send RPC request to a exchange
        3) A subscriber (RPC server) consumes the request, make a
        work and send a reply back using the unique key
        4) The caller receives the reply and unsubscribe from the

The must have failure scenarios to be addressed in the API docs:
        Use case #1 - Everything is working fine (no timeouts raised)

        Use case #2 - RPC client sent a request to an exchange and

        Use case #3 - RPC server consumes a request (ack it) and died
        without sending a reply back.

        Use case #4 - RPC client sent a request and connected broker
        node dies. RPC client didn't receive a confirmation envelop
        from the broker.
        There are three subcases - a request may be still delivered,
        a request is completely lost and a request is being duplicated.

        Use case #5 - RPC server consumes a request and sends ack
        back to broker node but the node dies.
        There are two subcases: a request will be acknowledge/removed
        from the queue and a request will be duplicated.

        Use case #6 - RPC server sends a reply back but a broker node
        There are two subcases: a reply is lost and a reply is

Blueprint information

Not started
Bogdan Dobrelya
Needs approval
Series goal:
Not started
Milestone target:
milestone icon 1.16.0

Related branches



Work Items

Work items:
Address expected behavior for the given failure modes in the spec: TODO
Figure out missing / unmatched expectations against the actual code's behavior: TODO
Submit patches to address missing / unmatched expectations: TODO

This blueprint contains Public information 
Everyone can see this information.