Send() returns an incorrect error if the context is cancelled about go-amqp HOT 4 OPEN

Agreed that for a canceled context we should return context.Canceled. For context.DeadlineExceeded this might lead to ambiguities. Assuming that the sender's mux isn't abnormally blocked, failing to write to s.transfers would indicate that the peer doesn't have any credit, so I don't think we want to paper over that.

from go-amqp.

failing to write to s.transfers would indicate that the peer doesn't have any credit, so I don't think we want to paper over that.

if this is a legitimate case, you would still want to fail matching the deadline provided on the context.
not block indefinitely there. At which point do you return an error that knows for sure that it's because the peer doesn't have any credit? it should know that before the deadline, And return an appropriate error. but if you do reach the deadline, it should always be correct to return DeadlineExceeded.

from go-amqp.

We won't block indefinitely if there's no credit. We'll return an *amqp.Error instead of a context.DeadlineExceeded error.

You bring up a good point about knowing ahead of time if there's enough credit. I'll take a look at that.

from go-amqp.

Thinking about this more. The lack of credit should be temporal. So, I'm hesitant to just outright fail the transfer as that could be racy (i.e. the flow frame is in flight with credit, we just haven't received/processed it yet).

There is a bit of ambiguity though. There are two places where the sender waits on ctx.Done(). The one we're discussing here and waiting for message settlement. Is it important to be able to distinguish between the two cases? i.e. in the former (no credit), should apps retry sending the message? Should they retry sending if we cancel/time out waiting for message settlement?

Maybe I'm overthinking all of this and just returning ctx.Err() is good enough.

from go-amqp.