Overlapping delivery for ordered subscriptions

[mgabeler-lee-6rs]

While "official" documentation is lacking, this blog post seems to provide the most detailed and quasi-official description of ordered delivery in pubsub[^1].

One notable item it notes is:

Streaming Pull (Via the Client Libraries) The client libraries guarantee that for any given ordering key, the callback is run to completion on messages in the correct order.

This statement makes sense for languages like Go and Java where the callback can actually do meaningful work before "completion", but for the NodeJS library, while it is technically true, it is unhelpful.

In NodeJS, almost any message callback that does anything more than add the message to another queue is going to need to be an async function returning a promise.

But since the library uses emit, any such returned promise is ignored.

This seems like a disconnect between the NodeJS client and the other languages. Is there any plan to address this?

Yes we can work around it in applications by making our own queues, but since the pubsub library already has a complex queue system of its own, this feels ... unfortunate.

[^1]: The fact that an ordered subscription can receive additional messages for an ordering key before prior messages are ack'd is a surprising thing, and extra surprising to only have it noted in a blog post and not described anywhere in the official documentation.

[feywind]

@mgabeler-lee-6rs Ah, thanks for bringing this up. We're gathering up points for a 2.0 API right now, and I've noticed several things like what you mentioned (e.g. with the publisher side flow control), that Java and the others can do it in a different (often more straightforward) way because they can block on threads, but Node can't. I hadn't thought of ordering keys in that context.

Also cc @kamalaboulhosn who wrote the article :D

[mgabeler-lee-6rs]

I'll say that article is excellent, I think integrating a lot of the detail there into the official documentation would be extremely helpful :grinning:

[kamalaboulhosn]

The Node library does adhere to the semantics of the ordering keys, ensuring that the callback is called for each message for a key in the proper order. Any asynchronous work done in that callback that needs to be processed in order is the responsibility of the callee. This isn't unique to Node, but perhaps more present due to Node's execution model.

[mgabeler-lee-6rs]

I respectfully disagree with the "This isn't unique to Node" assessment. Being single threaded and depending on futures for all async processing makes Node very different from C#, Go, Java, and Ruby. Only Python is similar to node here AFAICT.

I expect the vast majority of Node consumers have async processing for incoming messages at some point.