feat: await for describe queue subscription when subscribing to queues

[aymeric-agre]

Context

Masterbag inbound process failing sometimes.
https://cubyn.slack.com/archives/C3US319PA/p1661962354346349
TL;DR inbound was correctly done but missing describe queue was raising an error when refreshing the list of in transit masterbags.

Description

Queue with meta without any describe queue will most likely lead to timeout when calling {qualifier}:describe hence I think we should wait for its subscription as well.

[aymericbouzy]

Hum I think this is a breaking change. Previously the function was returning a Promise<ActualQueue> and is now returning a Promise<ActualQueue | DescribeQueue>.

[aymeric-agre]

You're right, will be better to just wait for it but still return the actual queue

[Guillaume-Pascal]

Agreed, I was confused as of why we raced this promise with the other ones (timeout and "subscribeToActualQueue"). Just awaiting it should work just as well, right?

[aymericbouzy]

I'm sorry, I did not quite understand how the issue was happening and how this change fixes it?

Since subscribing to a describe queue goes through carotte.subscribe as well, it also has the timeout : as long as we have a process.on("unhandledRejection", ...) (which is implemented by carotte-runtime and carotte-loader I believe), the error will cause the service to crash, no?

[aymeric-agre]

Because describe queue creation is handled when base queue is created through a call to subscribe, I think it's quite important to keep this strong dependency.

Also I don't think having a global process.on('unhandledRejection', ...) is a good practice. Every promise created in a function should be awaited or at least have a callback to be handled properly.

[Guillaume-Pascal]

I agree with this:

Also I don't think having a global process.on('unhandledRejection', ...) is a good practice. Every promise created in a function should be awaited or at least have a callback to be handled properly.

From there, I think awaiting the "subscribe to describe" promise is the simplest solution.

But maybe we could also run it in parallel with the Promise.race(timeoutPromise, subscribeToActualQueuePromise) with something like this:

await Promise.all([
  Promise.race(timeoutPromise, subscribeToActualQueuePromise),
  subscribeToDescribeQueuePromise,
]);

This way we don't delay the "actual" subscribe as much, but it's probably only saving some milliseconds