Skip to content

Add tag filtering to JobListParams - #1339

Merged
bgentry merged 2 commits into
masterfrom
bg/job-list-tags
Aug 3, 2026
Merged

Add tag filtering to JobListParams#1339
bgentry merged 2 commits into
masterfrom
bg/job-list-tags

Conversation

@bgentry

@bgentry bgentry commented Aug 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Adds exact tag filtering to job lists through explicit JobListParams.TagsAny
and JobListParams.TagsAll methods. The two filters can be combined, with
match-any and match-all groups joined to each other and other filters using
AND.

Tag predicates are added only when requested through driver-specific SQL
fragments. PostgreSQL uses native array overlap and containment operators,
while SQLite uses equivalent JSON predicates. JobDeleteManyParams is defined
from the list parameter type so their existing pointer conversion remains
structurally safe.

This is the core dependency for
riverqueue/riverui#548.

bgentry added a commit to golanglemonade/riverui that referenced this pull request Aug 2, 2026
@bgentry
use River tag list filter
d1585e3 
The job-list endpoint currently implements tag matching with PostgreSQL-only
SQL through `JobListParams.Where`, preventing the handler from working with
other River drivers.

Pin River to the commit from riverqueue/river#1339 and call the new
`JobListParams.Tags` method. River now owns the case-insensitive, match-any
query semantics for PostgreSQL and SQLite, while RiverUI remains independent
of driver-specific SQL.
@bgentry bgentry mentioned this pull request Aug 2, 2026
Merged
@bgentry
bgentry marked this pull request as ready for review August 2, 2026 00:02
@bgentry
bgentry requested a review from brandur August 2, 2026 00:02
bgentry
bgentry commented Aug 2, 2026
View reviewed changes
Comment thread client.go Outdated
}

jobs, err := exec.JobDeleteMany(ctx, (*riverdriver.JobDeleteManyParams)(listParams))
jobs, err := exec.JobDeleteMany(ctx, &riverdriver.JobDeleteManyParams{

@bgentry bgentry Aug 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah this needs to be kept aligned with list params, will fix

@bgentry
add tag filtering to job list
7ef57fe 
Applications that need to find jobs by tag currently have to use a
driver-specific `Where` predicate. That prevents shared consumers from
supporting PostgreSQL and SQLite with the same list query.

Add `JobListParams.Tags` with case-insensitive, match-any semantics and
carry it through each driver. PostgreSQL compares unnested arrays, while
SQLite compares the equivalent JSON array values.

Keep the list and delete-many driver parameter layouts synchronized so the
existing pointer conversion remains valid. Add shared driver coverage for
combined filters, transactions, and tag matching across every supported
driver.
bgentry added a commit to golanglemonade/riverui that referenced this pull request Aug 2, 2026
@bgentry
use River tag list filter
b9f3f97 
The job-list endpoint currently implements tag matching with PostgreSQL-only
SQL through `JobListParams.Where`, preventing the handler from working with
other River drivers.

Pin River to the commit from riverqueue/river#1339 and call the new
`JobListParams.Tags` method. River now owns the case-insensitive, match-any
query semantics for PostgreSQL and SQLite, while RiverUI remains independent
of driver-specific SQL.
bgentry
bgentry commented Aug 2, 2026
View reviewed changes
Comment thread job_list_params.go Outdated
@bgentry
make tag list semantics explicit
478b870 
The tag list filter exposes match-any behavior through an ambiguous method
name and folds case even though River preserves tag spelling. Its static SQL
also adds work to every list query and prevents PostgreSQL from using native
array operators.

Replace it with exact TagsAny and TagsAll filters. Build their predicates
only when requested through driver-specific fragments, using PostgreSQL
overlap and containment operators and equivalent SQLite JSON predicates.
Define delete parameters from list parameters so their pointer conversion
stays structurally safe.

Expand shared driver coverage for any, all, combined, case-sensitive, empty,
pagination, transaction, and low-level fragment behavior.
brandur
brandur approved these changes Aug 2, 2026
View reviewed changes

@brandur brandur left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one! Looks good to me.

@bgentry
bgentry merged commit dc39f53 into master Aug 3, 2026
15 checks passed
@bgentry
bgentry deleted the bg/job-list-tags branch August 3, 2026 00:42
brandur pushed a commit to riverqueue/riverui that referenced this pull request Aug 3, 2026
@golanglemonade @bgentry
feat: add ability to filter jobs by tags (#548)
ccb5f99 
* feat: add ability to filter jobs by tags

Signed-off-by: Sarah Funkhouser <147884153+golanglemonade@users.noreply.github.com>

* revert bad spacing change

Signed-off-by: Sarah Funkhouser <147884153+golanglemonade@users.noreply.github.com>

* finish tag filter support

Tag filtering arrives without changelog coverage or regression tests, and
mutations leave active tag-filtered lists stale. The autocomplete error also
advertises a `job_tag` facet that no backend implements.

Propagate tag filters through every active job-list cache key, remove the
unsupported facet claim, and document the user-facing filter. Add coverage
for repeated query parameters, route normalization, case-insensitive OR
matching, custom schemas, and the handler request path.

* use River tag list filter

The job-list endpoint currently implements tag matching with PostgreSQL-only
SQL through `JobListParams.Where`, preventing the handler from working with
other River drivers.

Pin River to the commit from riverqueue/river#1339 and call the new
`JobListParams.Tags` method. River now owns the case-insensitive, match-any
query semantics for PostgreSQL and SQLite, while RiverUI remains independent
of driver-specific SQL.

* strengthen tag filter coverage

The tag filter tests exercise backend matching directly, but they leave the
raw request boundary, route translation, and mutation cache behavior
unprotected. Regressions in those paths can silently ignore public API
filters or leave filtered job lists stale.

Assert repeated query parameter extraction and parser type dispatch. Add a
focused route component harness that verifies tags flow from route search
state into the job query and filter control, back into navigation updates,
and through the cache keys refreshed after cancel, delete, and retry.

* use explicit River tag matching

RiverUI still calls the ambiguous tag filter and describes its matching as
case-insensitive after River splits the API into explicit any and all forms.

Pin the River modules to the revised PR commit and use TagsAny for the
existing multi-selection behavior. Describe the exact-match contract in the
changelog and include a mixed-case decoy in handler coverage so accidental
case folding is visible.

* pin River merge commit

RiverUI currently points at the tag-filter PR's branch commit even though the
River change is now merged.

Move every River module to the resulting master merge commit. The dependency
now tracks the authoritative repository history while retaining the same tag
filter API and behavior.

* keep integration smoke test generic

---------

Signed-off-by: Sarah Funkhouser <147884153+golanglemonade@users.noreply.github.com>
Co-authored-by: Blake Gentry <blakesgentry@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@brandur brandur brandur approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@bgentry @brandur