Open richardpark-msft opened 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.
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.
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.
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.
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.