[service-bus] Receiving

[richardpark-msft]

The Service Bus receiver should allow for:

• A "receive forever" mode, where errors are reported to the user but recovery is automatic (and infinite - we can report errors to the user but we continue to try to recover even in the face of failures). This is the simple scenario, intended to work out of the box without much fuss. Sometimes this takes the form of a sample, but in JavaScript (and .net) this is built-in to the library.
• A "receive fixed number of messages" method, that lets you specify a number of messages to receive as well as a time limit to wait for them.
  NOTE: this was a big enough item that I moved it into [service-bus] Batch receiving #15156
• A "peek" method that lets you peek messages without affecting their delivery state.

Some additional options:

• An 'iterator' method that lets you retrieve your messages using your language-native async pattern. This might be similar to using a Go channel.

[richardpark-msft]

NOTE: these are just placeholders as I do my review of the library. It's possible that some of this is already exposed in the compliant way and no work will need to be done. I'll update this issue as I go.

[devigned]

An 'iterator' method that lets you retrieve your messages using your language-native async pattern. This might be similar to using a Go channel.

Definitely don't want to expose a channel through an exported interface. That why iterators in SB are the way they are.

[devigned]

An 'iterator' method that lets you retrieve your messages using your language-native async pattern. This might be similar to using a Go channel.

Definitely don't want to expose a channel through an exported interface. That why iterators in SB are the way they are.

[richardpark-msft]

@devigned:

An 'iterator' method that lets you retrieve your messages using your language-native async pattern. This might be similar to using a Go channel.

Definitely don't want to expose a channel through an exported interface. That why iterators in SB are the way they are.

That was an off the cuff idea, but I'm interested. It sounds like you're saying it's an anti-pattern?

[devigned]

In this case, it would difficult to ensure a consumer were to read all of the items added to the channel. I think it would lead to error prone code.

I don't see exposing channels as a 100% never do it thing (thinking about Context.Done()), but I think it is to be avoided as you are implying concurrency at the library level rather than letting the user of the library decide.

[richardpark-msft]

We have the two major receiving types - batch receiving via Receiver.ReceiveMessages(), non-destructive read (via Receiver.PeekMessages() and streaming via the Processor.

The iterative method was optional, so dropping for track 2.