Allow individual subscriptions to be removed

[fiznool]

Firstly, thanks for a great library. I've been skirting around the requirements for adding a job queue in my current project, and now that I've taken the plunge, I'm happy to have chosen pg-boss.

My question relates to the subscribe / unsubscribe dichotomy. It appears that if subscribe is called multiple times with the same queue name, a subsequent call to unsubscribe will remove them all. I was expecting something similar to node's EventEmitter structure, where a subscription setup with on can subsequently be removed with off, without affecting any other subscriptions.

I'm aware that subscribe kinda means something different in the job queue world vs standard pub/sub but I figured it might be useful to be able to remove individual subscriptions.

What do you think?

[timgit]

Would you include more information about your use case?

You are correct about how how unsubscribe() works, and I haven't adequately documented how multiple calls to subscribe() sets up additional workers in memory on a single instance, much less provided a way to reason about managing them independently in the api. This is an advanced usage pattern, and I only recently started using multiple subscriptions in my app on 2 high volume queues to reduce a specific concurrency race condition.

[fiznool]

Thanks for your quick reply.

I guess I don't have a specific use case for this - it was part of a wider understanding of how to gracefully shut down workers when the server restarts. In this use case, its sufficient to simply unsubscribe them all with the current unsubscribe implementation. However, the current behaviour surprised me a little, hence the question.

Feel free to close this discussion if it isn't something that is worthy to consider. But in case you might be interested in exploring further: I wonder if it would make sense to assign a unique ID to each worker? The returned promise from calling subscribe could be resolved with this ID, allowing the individual worker to be unsubscribed whilst retaining others (perhaps with an unsubscribeOne(workerId) call or similar, to prevent a breaking change). Going further, unsubscribeAll could be a decent name for the current behaviour, with unsubscribe remaining for backwards compatibility.

But, as mentioned this might be out of scope...

[timgit]

No problem at all. This is good feedback on how you'd expect it to work. If you'd like to submit a PR, I would prefer passing an optional second arg with something like { worker: [uuid] } instead of creating functions.

[fiznool]

Great, I'll see if I can find some time to work on this over the next couple of weeks. Thanks for your time!

[timgit]

This will be included in the 6.0.0 release