Job UI

[alachaum]

It would be useful to provide an optional UI - at least in development mode - showing the list of jobs pending, running, which ones have failed and the failure reason.

[lovitt]

@alachaum Curious what your current thinking is on a potential Cloudtasker UI?

The Google Tasks UI works OK for basic functions (monitoring, retrying, canceling) in production. But the base64-encoding of job names and arguments makes it hard to see what is going on. And of course there is no visibility into batch jobs.

I was wondering if a Mission Control adapter for Cloudtasker would be feasible. Non-ActiveJob functionality (batches, unique jobs, cron) would not be supported. But Mission Control already supports the notion of adapter-specific features, so perhaps this could be overcome.

Otherwise a purpose-built Cloudtasker UI would be welcome.

We are invested in Cloudtasker and Cloud Tasks for running background jobs. The lack of a good production dashboard UI is our only major pain point at the moment. I'd be more than happy to contribute to developing a solution.

[alachaum]

Hey @lovitt , my initial thinking was to deliver this UI only for development purposes, to give more visibility into failed jobs. As such, I was tempted to simply reuse and adapt the Sidekiq UI since it is completely self-contained.

Having said that, I'm pretty open to solutions. In any case, I think it is preferable to encapsulate this UI in a separate gem. This would give people control over whether or not they want to include this UI (and any gem it would depend on) in their production build.

The bulk of the UI should be a separate gem but we can always extend the core Cloudtasker adapter interfaces and add methods to easily list jobs (with pagination), cancel jobs, etc.

Providing the programmatic API above is probably the first logical step on core Cloudtasker. Once this is in place, the rest is more or less adaptation + cosmetic.

[codercr]

I know this is old. I would love to see this through Mission Control and adding SQL DB store option instead of only redis. I may myself look into making a SQL store option as it is more likely to have a SQL DB than Memstore DB.