Link errors need to be wrapped in an amqp.DetachError

[richardpark-msft]

Currently network errors will leave the link in a detached state (which is fine) but will not indicate that detach state via the returned error. In paticular, this code in Receive() can be problematic:

func (r *Receiver) Receive(ctx context.Context) (*Message, error) {
	msg, err := r.Prefetched(ctx)

	if err != nil || msg != nil {
		return msg, err
	}

	// wait for the next message
	select {
	case msg := <-r.link.Messages:
		debug(3, "Receive() blocking %d", msg.deliveryID)
		msg.link = r.link
		return acceptIfModeFirst(ctx, r, &msg)
	case <-r.link.Detached:
                // NOTE: 
                // NOTE: r.link.err is not guaranteed to indicate the link is detached (ie, it can just be a network error)
                // NOTE: 
		return nil, r.link.err
	case <-ctx.Done():
		return nil, ctx.Err()
	}
}

The bit NOTE'd above will cause errors if you're using the error to determine if the link needs to be recovered. In general a caller should be able to see amqp.DetachError{}, for instance, and know they can do something useful here, like recreate just this link.

[myusuf3]

is there a method to reestablish the link available to users of this library? on the sender side on stale connections.

[myusuf3]

just following up here. I am trying to update an upstream and hoping to avoid dealing with this at my level. How do you currently deal with stale connections on long lived receiver functions in worker environments?

[myusuf3]

@jhendrixMSFT I would contribute some effort into improving this does the team have a shared slack or something?

[jhendrixMSFT]

Fixed in v0.18.0