Repository navigation
Feature Request:JobCount() client function #1017
Description
There's a nice JobList method on the client that can be used to get back a slice of all jobs, according to some provided params (kind, state etc).
I've been using this - but just to get a count of the number of jobs of each kind in each state (I've made a prometheus metrics Collector that keeps track of the number of jobs by kind and state).
This is quite a heavy query as it's returning the whole JobRow - which includes a bunch of fields I don't really care about for this narrow purpose.
It'd be great if there were a lighter weight JobCount method that would just return a count of the number of jobs according to the parameters.
Activity
[-]`JobCount()` client function[/-][+]Feature Request:`JobCount()` client function[/+]danieljosephchambers commentedon Aug 15, 2025
Oh I've just spotted
JobCountByAllStatesin theriverdriverpackage. I guess it wouldn't be that tricky to expose this in the client?hasanmahira commentedon Nov 3, 2026
I'd like to add this: a
Client.JobCount(ctx, params)built on the existing driver count query, with tests for both drivers. Would you accept a PR?brandur commentedon Nov 3, 2026
Hrmm, sorry guys, but I think this is probably still a "no" unless someone's able to provide stronger justification as to why.
Any application using River is likely to be using its database for other things. Using its database for other things means that you've got some kind of data layer in place. Once you've got a data layer in place, it's not clear to me why it wouldn't relatively trivial just to issue your own
SELECT count(*) FROM river_jobwithout the River client needing to be in the mix.The downside to exposing more query functions the client is that the API devolves into too much of a mess. Even just the difference between
JobCountandJobCountByStateis significant, and if you start exposing one, you might have another request not long later to expose the other. Each needs a bunch of boilerplate code likeJobListalready has for filtering etc, and it adds up.So what I'd be looking for specifically in terms of rationale: (1) what the job count is for, and (2) why it's hard to do elsewhere and has to be on the River client. IMO functions like
JobGetandJobListhave a better raison d'etre because they're returningJobRow, which isn't trivial to build for yourself otherwise. A count is extremely trivial to build for yourself. I should note fairly too that if one of our Pro users really wanted/needed this, that'd add weight as well.danieljosephchambers commentedon Nov 3, 2026
Thanks for the reply @brandur. We ended up doing exactly as you suggest - just do our own
SELECT count(*) FROM river_jobwithout the river client. The only slight concern was whether there'd be a breaking migration to the River schema at some point which might break this query - but it seemed like an incredibly small risk and easy to deal with if it ever did happen.brandur commentedon Nov 3, 2026
Awesome to hear! Thanks for the quick reply. Yes, I think safe to say at this point that
river_joband its core columns likestateare going to be around as long as River itself is. Very, very infinitesimal chance of breakage there.