workers not running

[vsoch]

Hi! I have a setup that I'm trying to get working here and I'm trying to do a basic job Insert, and then verify that the worker is running. I've tried everything I can think of to do, and although I see that the insert returns a jobid (and reports adding to the queue):

I0726 05:04:53.118934       1 scheduler.go:463] "[FLUXNETES]" Starting="queue"
I0726 05:05:44.320325       1 podspec.go:96] [Jobspec] Pod spec: CPU 1, memory 0, GPU 0, storage 0
I0726 05:05:44.350166       1 queue.go:146] Job 1 was added to the queue

I never see any indication that the job is running - meaning in the Work function, I can put different kinds of prints and nothing ever shows up. Subscriptions also never fire, and logging to klog, slog, or to file doesn't work. Here is where I create the queue, and here is the Insert (Enqueue) function and the package that has the worker, etc. I think I am likely doing something wrong with a context or Start/Stop but I don't know enough about this library structure to understand what is right.

Last time you just converted my question to a discussion without answering, so I had to guess, and I suspect I did it wrong and am now layers deep into that error. Please help me this time. 😞

[bgentry]

Hi @vsoch, we try to reserve Issues for actual confirmed problems. And while we do our best to help people with questions, we don’t always have time.

I tried looking at your example but it seems fairly complicated given you’re integrating with kubernetes. My advice would be to check out the code examples within River like this one as well as the standalone documentation: https://riverqueue.com/docs

It seems like you are probably managing to insert a job given the log line, and you could verify this by querying the river_job table in Postgres. If no jobs are getting worked it’s likely that you haven’t started a client connected to the same database, or haven’t configured one to process jobs on the same queue name as you’re inserting on.

[vsoch]

It's working! It was really simple (I think?) I didn't realize the Kind() needed to match the name of the args and worker (I had "job" for QueueItem (the args) and QueueWorker). When I changed to JobArgs and JobWorker and Kind Job I (finally) see some output that indicates the workers are doing something!

I apologize for my previous message - I didn't get notification for the original discussion response, and thought it was some kind of strategy to not answer the issues. I do think this is important enough to warrant an update to docs - for context I was reading here:

https://riverqueue.com/docs#job-args-and-workers

And it would have been helpful to have a callout or warning that stated the need for the matching name, etc. I definitely suspect it could be elsewhere in the docs (your documentation is beautiful) but that's where I was reading. I only figured it out after reading example after example for an entire day (and in retrospect I feel very dumb).

[vsoch]

Here are the changes I did:

+ type JobArgs struct {
- type QueueItem struct {
	ShouldSnooze bool `json:"shouldSnooze"`
	GroupName string `json:"groupName"`
}

// The Kind MUST correspond to the <type>Args and <type>Worker
+ func (args JobArgs) Kind() string { return "job" }
- func (args QueueItem) Kind() string { return "job" }

+ type JobWorker struct {
- type QueueWorker struct {
+	river.WorkerDefaults[JobArgs]
-	river.WorkerDefaults[QueueItem]
}

I'll try looking at the code later to understand why this didn't work without that - I suspect with the wrong string it isn't able to link up the new work item with a worker that can complete the task. I am wondering if not seeing the client.go / producer.go messages meant I was also missing an error message somewhere!

[bgentry]

I'm not quite following what was broken here. The Kind() value is read at insert time because it is written into a corresponding database column. When a job is fetched from the database, the kind string is used to match up the job with a corresponding worker. This is all done behind the scenes using the Workers config you give to your Client when creating it.

So as long as you're not running different code on different machines where this Kind() value resolves to different values, you shouldn't have to worry about it. The only important things to do here are (a) make sure you're using a unique Kind() string to name each of the types of workers you're creating, and (b) be sure to register your workers on a Workers bundle using AddWorker so that your Client knows how to work this kind of job.

[vsoch]

I don't understand it fully, but when I just had "job" there I never saw any output beyond the job id being submit - no output from the worker or other indication the worker was running. It could be a one-off chance that it worked - I regularly rebuild and start everything again so I can report back if it stops working again.