Roadmap

[tobytwigger]

This discussion contains the roadmap/todo list for this package.

If you see something you'd like to contribute, open an issue to discuss or submit a pull request.

• Move all checking of if a status has finished or not to the enum, to make it easier when we add statuses.
  • This predominantly involves some isFinished type functions on the enum
• Show when middleware releases a job · Issue #66 · tobytwigger/laravel-job-status
• Handle listeners nicely
  • Show the listener class instead of CallQueuedHandler
  • Save information about the event
• Check the dashboard works well with trimmed jobs, and fix if it doesn't.
• Handle when the worker stops unexpectedly
  • I think this may happen when the worker emergency stops! A 'WorkerStopped' event is fired at this point.
• [Dashboard] Jobs list needs a responsive table row
• Figure out how not to commit public files from the dashboard
  • Possibly by using quasar serve to avoid needing to compile in development
  • Possibly pulling the dashboard into a new package
• [API] Reduce/Optimize query for /jobs list · Issue #63 · tobytwigger/laravel-job-status
• Limit what properties are returned based on an API query. Should pass, e.g. ?properties=id,name,runs to return only the given properties.
• Can we reduce the number of db queries made by the database
• Fix page results changing as new jobs get added to the top
  • When I'm looking at a page of runs, I don't want the jobs on that page to change. If a new job is added in the background, I shouldn't see a change in my page. Unless I'm on the first page? This will need some thinking about, since I'd like to keep it easy to jump to a specific page rather than having to click 'next' and using the previous job status ID.

Lower Priority

• Convert client package to eslint
• Fix issues raised by the js linter
• Use js types from the new client package
  • Types were defined in the laravel-job-status dashboard package, but are now defined in laravel-job-status-js. Should use these in the dashboard!
• Handle the dashboard API returning 404 and 403 errors.
  • Should show the user a nice error page rather than silently failing and staying on 'loading'.
• Sort the demo page looking nicer on mobile
  • The demo page (https://job-tracker.gpsvault.co.uk) is too wide for a mobile, so I have to scroll horizontally to view the rest of the toolbar links.
• Job running icon isn't always displayed?
  • Haven't yet been able to recreate but worth testing in different browsers
• Add docblocks to classes users may interact with
• Check all github actions use valid versions of node/php. At least some use node 12 and should be updated
• Resolve anything raised by phpstan
• Improve error messages from the JobRetrier validation.

Update docs

• Add examples to the programmatic history section
• Flesh out using the modifier to retry, cancel and send messages to the job
• Add client methods including pagination and searching by batch id
• Setting up a dev environment to edit the dashboard easily

Future Ideas

• Add websockets
• Save configuration of jobs, such as max tries and max exceptions
• Tidy up the collection code to make sure it's easy to understand and DRY
• Add a data timeframe to the dashboard, to only get data that's happened between a certain point.
  • This is useful for if we trim successful jobs, so a job doesn't look like it only has failed jobs. We'd limit the time frame through the dashboard UI to only retrieve jobs that have started since we last trimmed successful jobs, to get a full picture of our job.
• Add filtering to the dashboard pages
• Write a testsuite for the JS client
• Able to change the polling time for the JS client, through the dashboard, the client and able to set a sensible default in config.
• Link a job dispatched by another job.
• Hook into the logger to save a message any time we use Log::.
• Add a way to benchmark parts of a job (e.g. a name and a time for a callback to be executed).
• Able to bind the job percentage to an array, to automatically iterate up the percentage through the array. E.g. https://laravel.com/docs/9.x/artisan#progress-bars.
• Improve the readability of the queue listeners, using more util classes rather than inheritance.
• Do up the demo site
  • Show the code from the job that will run, so users can see the exact job
  • Show a user their jobs on the demo site from the main page. Will need to log in a user whenever you load the page (e.g. using a cookie), tag the jobs with the user then see a list of their jobs.
• Add more analytics to the dahsboard · Discussion #64 · tobytwigger/laravel-job-status
• Able to mark a failed job status/exception as 'handled'.
  • This would allow us to do things like mark an exception as reviewed or solved.
  • Users could 'dismiss' a failed run through the app (e.g. a popup that says 'your file was not processed'). This marks the exception as handled, therefore we don't load it through the API any more and so the user sees 'upload a file' not the error.
• Show how long a job has been released for if released (e.g. when delayed by a rate limiting middleware)