Change background job notification timing

[andrewmckaskill]

Prerequisites

• I have added steps to test this contribution in the description below

Description

This PR changes the timing of the "Executing" notification for recurring background jobs.

The sequence of notifications for successful and failed jobs does not change. Only the sequence for ignored jobs changes.

Sequence for SUCCESSFUL jobs:

1. Executing
2. Executed

Sequence for FAILED jobs:

1. Executing
2. Failed

New sequence for IGNORED jobs:

1. Ignored

By comparison, the old sequence is:

1. Executing
2. Ignored

Reasoning

By moving the notification directly in front of the actual call to the underlying job it removes a number of "false positive" executing notifications for jobs which would be stopped due to one of the check conditions (runState, serverRole, mainDom).

If the job is being ignored due to one of the check conditions it should not be considered executing.

Additionally, if the executing notification were being hooked to update a database or other external system, the notification handler would need to check that the runState, mainDom, etc were valid. During testing this proved troublesome as the jobs often started BEFORE the database setup was complete and resulted in a number of attempts to access databases that were not present.

[github-actions]

Hi there @andrewmckaskill, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[lauraneto]

Hi @andrewmckaskill ,

Thank you for the pull request! 🙌
A member of the Core Collaborators team will have a look at it as soon as possible. 🙂

[mikecp]

Hi @andrewmckaskill ,

This makes sense indeed!

I just wanted to make sure you had thought about the fact that if something goes wrong while checking the "Ignore" cases, you will end up directly in the "catch" part and then end up with just "Failed" instead of "Executing - Failed" as now.

It's probably an edge case now, but who knows how this logic might evolve + as I said, I just wanted to check if you had evaluated/considered that case 😉

Cheers!

[andrewmckaskill]

Hi @andrewmckaskill ,

This makes sense indeed!

I just wanted to make sure you had thought about the fact that if something goes wrong while checking the "Ignore" cases, you will end up directly in the "catch" part and then end up with just "Failed" instead of "Executing - Failed" as now.

It's probably an edge case now, but who knows how this logic might evolve + as I said, I just wanted to check if you had evaluated/considered that case 😉

Cheers!

Hi @mikecp - yes, I had considered it. I wanted to get the first round change in straight away after I identified the problem.

Let me go fix it up now. Given that an exception in the built-in umbraco services is unlikely (as there would be much more catastrophic consequences if they start failing) - I'll rework to limit the notifications to the user job code and leave high level exception handling to logging only.

[andrewmckaskill]

Ok - that's done now. I've moved the try/catch block to be JUST around the job's execute method. If there is an exception in one of the other umbraco services, it'll bubble up to the try/catch in the wrapping RecurringHostedServiceBase . As that ExecuteAsync method is run from a timer on a background threadpool thread it needs to have a try/catch on it so that any unhandled exceptions don't cause the whole application to stop.