Handling non-retryable errors

[eric-gonzalez-tfs]

Hello all,

Thank you for the hard work on pg-boss! We find that the library is well thought-out and is constantly improving.

I have some jobs set up using pg-boss's retry mechanism. However, there are scenarios where the current job may fail, but I do not want to retry due to a fatal error. I've tried adding a call to boss.fail(name, id), however, when the job bounces out of the handler, it appears to set it back to a "retry" state.

What is the best approach to telling pg-boss that a failure happened, but we do not wish to try again?

Thanks!

[timgit]

To opt out of the configured retry, the only option I can think of is to delete it

[rrindels]

We do something similar with deleting the current job but creating a new job with our original payload +additional error payload in another queue which are handled with different specialized workers.

On Thu, Oct 17, 2024, 1:49 PM Tim Jones @.***> wrote:

To opt out of the configured retry, the only option I can think of is to delete it

— Reply to this email directly, view it on GitHub https://github.com/timgit/pg-boss/issues/516#issuecomment-2420292003, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQQDAF3G62O34J55WPKK5LZ4ABEPAVCNFSM6AAAAABQEGIENWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRQGI4TEMBQGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[eric-gonzalez-tfs]

Thank you for the feedback!

I ended up calling boss.cancel which appears to accomplish this. The job being in a "cancelled" state also lets us differentiate between a job that was completed, failed and cancelled (likely due to a fatal error).

[timgit]

That also works :)