Azure / go-amqp

AMQP 1.0 client library for Go.
https://github.com/Azure/go-amqp
MIT License
104 stars 56 forks source link

Send() returns an incorrect error if the context is cancelled #309

Open richardpark-msft opened 1 year ago

richardpark-msft commented 1 year ago

Today you get back this error:

Error{Condition: amqp:link:transfer-limit-exceeded, Description: credit limit exceeded for sending link dx-pqVSDqo0PVdKQEeXLLDbJo25byEAW-CJCn6CxPLZEgdV5E-bDCQ, Info: map[]}

Coming from here: link

Now that we have proper rollback if sends fail/cancel I think we can safely return context.Canceled or context.DeadlineExceeded if there were no side effects worth reporting.

jhendrixMSFT commented 1 year ago

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.

serbrech commented 12 months ago

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.

jhendrixMSFT commented 12 months ago

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.

jhendrixMSFT commented 12 months ago

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.