Skip to content

Document maintenance scope for clients sharing a schema #1371

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
yafi-s wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Document maintenance scope for clients sharing a schema #1371

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions docs/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,19 @@ if err := riverClient.Start(ctx); err != nil {
`Workers` can also be omitted, but it's better to include it so River can check
that inserted job kinds have a worker that can run them.

### Sharing a schema between clients

By default, clients using the same River tables elect a single leader to run
maintenance services across all queues. `Queues` controls which queues a client
works, but does not limit the leader's maintenance scope. For example, the job
rescuer can discard a stuck job from another queue if its kind is not registered
in the leader's `Workers` bundle.

Clients sharing a schema should register all job kinds that may need rescue,
even when they work different queues. For independent applications with separate
worker registries, use separate Postgres schemas and set `Config.Schema` on each
client. Migrate each schema before starting its clients.

### Stopping

The client should also be stopped on program shutdown. There's a number of ways
Expand Down