Hangfire: Trigger recurring task doesn't update the Last Executed Time

Created on 28 Oct 2014  Â·  15Comments  Â·  Source: HangfireIO/Hangfire

As the subject states, triggering a recurring task through the Dashboard doesn't update the Last Executed Time.

Is this as intended or a bug?

core problem

Most helpful comment

Is this feature still being planned? The ability to run "all" missed jobs upon startup important for some scenarios.

All 15 comments

You can look at the RecurringJobManager class – there is no any reference to previous or next executions, only information about job itself and its cron. Only RecurringJobScheduler knows about other runs.

That is why I didn't introduce the logic to update information about other invokes when I wrote the Trigger method (I wrote it after AddOrUpdate and RemoveIfExists methods) – just not to introduce unnecessary things.

But if it leads to confusion, we can always change the things. In what use case you are using the Trigger method?

The main reason so far to trigger a ScheduledTask manually has been if a daily task didn't run because the website was shut down. Its not that much of an issue anymore since we implemented the logic mentioned here http://discuss.hangfire.io/t/run-missed-recurring-jobs-at-system-startup/331.

Imo a run is a run, whether it was manually triggered of ran because of a cron-trigger.

to trigger a ScheduledTask manually has been if a daily task didn't run because the website was shut down

Hangfire runs skipped recurring jobs automatically. I've created a background job with */5 * * * * cron and did the following steps with the following results:

// Server started 13:34:31
17.11.2014 13:35:02
17.11.2014 13:40:02
Server stopped at 13:41:11
Server started at 13:46:34
17.11.2014 13:47:08 – missed run for 13:45
17.11.2014 13:50:08

But only last missed run is being triggered. I.e. if I'd run a server at 13:51, the result would be:

// Server started 13:34:31
17.11.2014 13:35:02
17.11.2014 13:40:02
Server stopped at 13:41:11
Server started at 13:51:56
// Missed run for 13:45 will not be invoked
17.11.2014 13:52:08– missed run for 13:50

However, it is possible to run all skipped jobs, but it requires small easy changes.

Interesting, i haven't experienced this behavior. I tried doing a search in the code but couldn't find any mentions of "missed run for" https://github.com/HangfireIO/Hangfire/search?utf8=%E2%9C%93&q=missed+run

So, the documentation should be updated to include the information about what Hangfire will do for missed runs. Regarding to the Trigger method – I think this issue is not indicative enough to update the semantic of the method as missed runs should be handled in other ways.

We could also provide a way to specify missed action for recurring jobs:

enum MissedRunAction
{
    DoNotRun,
    RunLast,
    RunAll
}

RecurringJob.Add(() => Console.WriteLine(DateTime.UtcNow), Cron.Daily, MissedRunAction.RunLast)

What do you think?

In regards to MissedRunAction, i like this very much. Its the same basic idea we had at out end, adding a setting on a job whether a job is allowed to do a delayed run or not.

I can't imagine a scenario where you would want to run all missed runs, and not just the last though. Its not like you DateTime.Now is being overridden by a time in the past, so you don't achieve anything by running a Scheduled Task 5 times right after each other, instead of just one.

Unless of course the schedule task updates a counter or something... allright, MissedRunAction.RunAll might make since in some edge case scenarios :)

In regards to the trigger, its not always about running missed jobs. We have another scenario where a job synchronizes a database of 100.000 records every night. Sometimes the customer, for reasons we don't care too much about, needs to trigger the synchronization now instead of waiting for the nightly run.

So far we use the LastExecutedTime stamp of the job to see when it ran the last time, but since the trigger don't update the value, we need to maintain our own timestamp as well to see when the synchronization was last done.

:heavy_plus_sign: :one: to MissedRunAction.
We are expecting some issues in jobs not triggered here.
Is it really triggered again when the server is re-started? We think that sometimes the server goes down for some time and then the recurring jobs are being skipped.

@odinserj how's the progress on this one?

In my case, I have a recurring job, which is run monthly, but if the client triggers it (say in the middle of the month). Last job state and last execution date are not updated, this really confuses the client ;x

Maybe it can updated by hand, or loaded from different API? I'm using .GetRecurringJobs() method now.

This would be a great feature.

I use hangfire for infrastructure automation tasks.... Rebooting servers, and things which are very time critical.

If for some reason, it was unable to execute during its schedule, It would be extremely helpful to not execute the job.

Is this feature still being planned? The ability to run "all" missed jobs upon startup important for some scenarios.

I'm running into this as well in a use case closer to what burningice2866 and several others mention. It has nothing to do with missed recurring jobs - just wanting to allow users to run what would normally be a scheduled job in a ad-hoc manner. RecurringJob.Trigger(jobid) does run the job as expected, this but does not update LastExecuted. The behavior I expected was that it would update LastExecuted both in the dashboard and in the RecurringJobDto returned by JobStorage.Current.GetConnection().GetRecurringJobs().

At this point, I could see an issue changing this behavior breaking code that expects the current behavior. In that case, one potential fix would be an overload that allows changing this behavior:

  RecurringJob.Trigger(jobId, shouldUpdateLastExecuted)

I also want to know if functionality to trigger a recurringJob and have it update LastExecuted values is still being planned?

My scenario is that we have multiple queries that need to be ran on a daily basis and we are adding a dashboard page specifically for viewing the status of that subset of all of our hangfire jobs. If any of the queries failed for any reason they need to be able to be re-ran from this new dashboard after the source of the error is fixed; in which case we then run into the issue of the re-ran query may have been successful, but because it doesn't update any of the LastExecuted values we can't show that the status went from Failed to Succeeded.

Still an issue. Could we at the very least get an optional updateLastJob parameter on the Trigger method?

In our case we have a recurring job which retrieves data every 20 minutes, however if someone views this data and wants a fresh set they can manually fire the job, but this doesn't update the last executed time (which they use to judge wether or not to manually fire the job)

Call to the Trigger method now updates LastExecution field in the latest 1.7.0 betas, so I'm closing this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jeffsugden picture jeffsugden  Â·  4Comments

odinserj picture odinserj  Â·  4Comments

cottsak picture cottsak  Â·  3Comments

osmanrahimi picture osmanrahimi  Â·  3Comments

plmwong picture plmwong  Â·  3Comments