Q:

How to handle rejected messages in AMQP.Net Lite

I have a client/server setup between a web api and an azure webjob using AMQP.Net Lite.  
The requesting client looks something like this:
sender. Send(request, (link, message, outcome, state) => {
        requestOutcome = outcome;   //This indicates accepted even if rejected! 
    }, null);
var response = await receiver. ReceiveAsync();
return response. GetBody<TResponse>();

The server looks like this:
try {
    // Process the message and generate response if valid
    var response = await _messageHandler. ProcessAsync(message);
    _receiverLink. Accept(message);
    Logger. Info("Message has been processed");
    if (response ! = null) {
        _responderLink. Send(new Message(response));
        Logger. Info("Sent response");
    }
} catch (Exception ex) {
    Logger. Error(ex);
    _receiverLink. Reject(message, new Error{Description = ex. Message});
}       

I can send and receive messages from the client, but in the case that the request fails, it seems AMQP has a mechanism for handling that via its request outcome using _receiverLink. Reject(), rather than explicitly sending some kind of error as a response.  According to AMQP docs that should send the message to the dead letter queue, and I would expect that also to provide a rejected status as the outcome to the sender.  However, it what I get is "accepted" instead.  
How can I get the Rejected status from the client side in order to appropriately handle the error? 
UPDATE
I see now the outcome is only related to the delivery to the queue, not the receiver accepting/rejecting it because the callback is received before the server handles the message.  Does this mean there is no way of handling the rejected status from the client side? 

A:

Correct, there is no built-in way to handle the server's reject from the initiating client.   This is because you have an intermediary standing between your client and server, a message broker.   The broker takes ownership of the message (it is no longer "in flight"), decoupling the client and server communication, including the kind of delivery status you are talking about. 
When your server rejects the message and the broker places it on a DLQ, it is placed there simply for out-of-band processing.   There is no standard behavior that propagates the error back to the originating client. 
So, in the end, you do need an error response message for this scenario.