That’s what it is has to be. I mean it must stay on processing state. If you are having problem with this flow; the problem is not on the flow, it’s on your code and logic.
Try to migrate your code to this flow. Probably using batches is gonna solve your problem Dont make batch operations in one job. For example if u gonna sen 100 emails, create 100 different job. Dont create a loop in one job. If u do that u have to face with thoose challanges
We do a single long running call (to an external library)
In some situations this library used all the available memory erroring out in an OutOfMemory exception
This killed the App Pool
The app pool would restart, the process restarts and kills the app pool again … and so on
I’m very well aware, that there are deeper problems which need to be fixed (more precisely which have been fixed already), but we want to prevent, that in future situations we run into this “endloss loop” again of hangfire processes killing the IIS app pool over and over again.
Looking for a solution for this as well. For a simple example, start a long running job (e.g. w/ Task.Delay), and then stop the parent process w/ CTRL+C. Starting the process back up automatically resumes / retries that job, even when using the AutomaticRetryAttribute Attempts = 0 global filter.
We’re looking for a way to conditionally disable this behavior for the same reason explained above: for failure cases where the same job just keeps getting run over and over with no ability to stop that behavior.