search

riverqueue / riverui

A web interface for River, fast and reliable background jobs in Go.
https://ui.riverqueue.com/
Mozilla Public License 2.0
49 stars 3 forks source link

Implement job delete backend API and UI call #19

Closed bgentry closed 3 weeks ago

bgentry commented 3 weeks ago

@brandur I'm implementing this as a JobDelete method in the main package. It will delete the job row if it exists and is not running. However, I'm a bit unsure of what to do for a return value:

  1. If I follow the pattern of JobRetry and always return the row values, you can't actually tell whether the job was deleted or was skipped over due to being in running state. I could add some logic in Go to sort of duplicate the logic in the query and look at whether the returned row was running or not. What gets returned to the user though? (*JobRow, bool, error)?
  2. I could just make the query an execresult and surface (bool, error) from it with a bool for whether the row was deleted. However this cannot distinguish between "job wasn't deleted because it didn't exist / was not found" and "job wasn't deleted because it was running". It seems we would still want to surface a not found error, so I don't love this option.

Thoughts? I can PR what I have if you'd prefer to comment on that.

brandur commented 3 weeks ago

What do you think about returning an error? Something like ErrJobRunning? This would be a rarer edge case.

Other ones don't seem too bad, but always better IMO to return two values instead of three from functions unless there's a good reason not to.