Interested contributor, anything that needs work?

[weakphish]

Hi! I'm very interested in contributing after getting frustrated with the existing ecosystem and seeing Arq get abandoned (?)

I only see one open issue that already has some movement - is there anything else that y'all would like some eyes on? Would love to help where I can!

[Graeme22]

That would be great! Yes, unfortunately arq does seem to be abandoned--if it weren't, this library probably wouldn't exist. I don't know if that's a permanent thing or not, but it seems like Samuel/the pydantic guys are really focused on their main libraries and AI stuff right now, which is fine! The things currently pending are:

• Have a look over the docs to make sure everything makes sense to a new user and see if anything is unclear or missing.
• Update benchmarks (they're super outdated right now!) Enqueuing should be faster than before but everything else a bit slower now that we're using coredis instead of redis-py, which has slower response encoding/decoding. These are in the benchmarks folder and ideally would be run on a relatively capable, modern machine. Docs would need to be updated with results (and competitor libraries updated to latest versions as well).
• Test coverage is at 96%, ideally I'd like to get that number to 100% and also think through scenarios that might fail in specific circumstances that are covered currently. This would require a pretty good understanding of the library (but thankfully it's still pretty small all things considered). Currently Redis Sentinel is supported but has no test coverage at all, I haven't gone through the work to get everything spun up correctly in the Github Actions environment. I do have this Docker Compose script which I used to test locally: https://gist.github.com/Graeme22/f54800a410757242dbce8e745fca6316
• Worker info page in web UI
• The web UI could definitely continue to improve, maybe adding some charts or statistics like turnaround time, average wait time etc. Some of the code currently only used in the web UI might also be useful generally and could be improved and moved to the main library (eg a function get_tasks for getting all tasks from Redis with a given status/statuses, with paging.)
• Queue TTL to automatically dequeue jobs that wait too long

I feel like the library is pretty stable at this point and mostly where I want it, it just needs more eyes on it and regular users to ensure it's production quality.

...and now we have an official roadmap haha! Thanks for asking and any help is appreciated.

[Graeme22]

Awesome!

[espdev]

A couple of my wishes.

• About WebUI it would be nice to have info about workers and what tasks are running at each worker. It's also a good idea to add an empty string to the filters so you don't have to reload the page every time to reset the filters. By the way, the filter by task name seems to be broken in WebUI now, task names are not displayed for some reason.
• ttl for the queued state of the task. Now, to dequeue a task from the queue we need to essentially call abort. But there doesn't seem to be any way to set an automatic dequeue after a given time.

[Graeme22]

Hi @espdev please open an issue for the web UI problem you mentioned, I can't reproduce. These are good ideas, I'll add to the list!

[Graeme22]

As for the empty string, that's unnecessary, you can just deselect everything in the multiple select

[espdev]

@Graeme22

I figured out why I don't have tasks displayed in the filter in the WebUI. I only register them on the workers, but not in the application where I do enqueue tasks and connect the WebUI. list(worker.registry.keys()) in _get_context just returns an empty list.

As for the empty string, that's unnecessary, you can just deselect everything in the multiple select

Indeed, it works if I use Ctrl + mouse click. Thank you! :)