Problem/Motivation
The queue listing page is a view so people can customise it, except that you cannot add a filter for the payload. This is probably because it is serialized data, but with the recent new feature of being able to retry failed jobs, it is almost impossible to find jobs to retry without being able to search by payload.
For example, we have 65000 jobs in the queue. We are completely unable to use the retry feature because there is no way to find a job to retry, so we still have to manually search in the database using a LIKE query to find a job with a particular payload (e.g. search for an order number in a recurring order).
Steps to reproduce
Edit the advancedqueue_jobs view and try to add a filter for payload.
Proposed resolution
Expose the payload field to views as a string so that it can be used with a "contains" field by anyone who wants to.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | CleanShot 2025-07-15 at 13.13.53@2x.png | 184.53 KB | alexpott |
| #10 | CleanShot 2025-07-15 at 13.14.10@2x.png | 184.08 KB | alexpott |
| #10 | CleanShot 2025-07-15 at 13.14.24@2x.png | 94.84 KB | alexpott |
| #2 | advanced_queue-3406601-2.patch | 397 bytes | rob230 |
Issue fork advancedqueue-3406601
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
rob230 commentedPatch for this.
Comment #3
rob230 commentedComment #4
ippy commentedNice one, thank you for a very simple but useful addition. I stumbled here when checking whether such a feature existed. The patch applied cleanly to * 1.0.0-rc7 (Drupal 9.5.9)
Being able to search through thousands of payloads in order to identify and/or retry or remove the occasional job is really very helpful.
This enables a UI approach that admins can understand and make use of, here to avoid spamming customers who did not attend an event. A (custom) cancel event occasionally fails to fire - leaving notifications remaining in the queue rather than being identified and deleted automatically. Being able to quickly identify these is great.
Overall this seems like a useful and non-controversial addition to the project.
+1
Comment #5
jcnventuraThis is not really a bug, so moving it to the correct category. Also, there is a patch proposed, so the correct status is "Needs review".
And finally, maybe @ippy would like to change the status to "Reviewed & tested by the community", so that this actually has a chance of being committed?
Comment #8
it-cru@jcnventura: I've tested patch #2 from @rob230 on D10.4 with advancedqueue 8.x-1.4 and it worked as expected. Before patch payload field was not available as filter in views. After apply of patch it was available and also useable as exposed filter to search advancedqueue payload of items for user given strings.
I've created a MR against 8.x-1.x which is based on #2 patch without any additional changes.
Moved issue to RVTC.
Comment #10
alexpottI've tested this MR and added the filter to the default view provided by the module so new sites will benefit. Existing sites can add it themselves as updating existing views is harder and there are situations that are hard to account for.
Test evidence
Comment #11
alexpottComment #12
alexpottI think this is more of task than a full on feature request.
Comment #14
alexpott