Preventing "job kind is not registered in the client's Workers bundle" errors with multiple clients

[rokf]

Hello,

I have the following scenario:

• 3 executables
• one database
• one schema
• one instance of River tables in that schema
• each executable has its own set of workers and a client that's managing those workers

I frequently see the job kind is not registered in the client's Workers bundle error because clients don't know which messages they'll be able to process when they pick them up from the database.

Now I am wondering, what would be the best solution to handle this if I want to keep the workers separated into multiple executables while using the same database within PostgreSQL?

Should I have separate schemas with separate tables for River, one schema and set of tables per client, as long as each client has a unique set of workers? There can of course be multiple instances of the same client using the same schema running the same set of workers, but this doesn't matter for this question.

I'd like to keep the transactional enqueueing guarantees across the whole project, which means a single database.

It's also possible that I simply missed something in the documentation, i.e. some configuration option that'd make this work without separate schemas.

Thank you!🙂

[brandur]

Hi @rokf,

We don't have a great way of accomplishing what you're trying to do. The closest would be to use separate schemas for two separate River installations, more information on which you can find here [1]. This is still not perfect though, because the PG listen/notify channel that River uses to detect new work will still be shared, so different clients will receive notifications for work that they can't do. This probably isn't the end of the world (I'd expect it to still work), but workers will be waking up and fetching more often than necessary.

@bgentry and I have been talking about the shared listen/notify channel, and I think we will find a way to fix that within the next few months, but it's still a problem for now.

@bgentry One other idea that comes to mind relating to this: we might be able to an additional filter to the job fetch query that looks for only known job kinds like kind = ANY(known_kinds::string[]) that'd solve it (modulo the same listen/notify problem). It'd be nominally less efficient though, we might want to support it with a flag like FetchKnownJobsOnly: true or something like that. Thoughts?

[1] https://riverqueue.com/docs/alternate-schema

[bgentry]

I might be misunderstanding the situation, but is there anything preventing you from using separate queues for each of these clients that’s working jobs? Clients will only work jobs on queues that are specified in their queue config, so you can pretty well isolate these from each other just doing that. You could specify the default queue on a per job type basis to automatically put them in a queue that’s handled by the worker you want to pick it up. Or you can specify the queue in the InsertOpts at insertion time to explicitly send a job to a given queue.

The option of using multiple Postgres schemas still has some issues that we're working through as @brandur mentioned.

[rokf]

Yup, can confirm, it works great. Thank you! 😃

I wasn't thorough enough when reading through the documentation as it seems. I believe that the queue concept and its usage patterns could use a section of their own in the documentation though, they aren't described that well 🤔

[brandur]

I'll take another pass at the docs and see if a "queues" page or some such would make sense as a good addition.

[rokf]

Thank you 😊

[brandur]

No worries! Added new doc page here: https://riverqueue.com/docs/multiple-queues

[rokf]

I've read through it, it's great 🙂 I also like how you've described the proper way to rename queues at the end. It's the cherry on top of the cake 😄