Here is a tricky thing. It occurs on only one task, server 5.7 or 5.8. On this task, the hour displayed in the journal log is 1 hour shifted. For example, the jobs starts at 8:30 AM Paris time but it shows 9:30. It does not always do that and it's only on this task. Well I'm note sure it only concerns this task but this task is particularly important for us so we noticed it.
Would you be able to check why it would do that ? I have tried to recreate the task but the same thing happened today: the task was run at 10:48 AM Paris time and the log shows 11:48. And it's a bit strange because the log stopped at 11:49 which was the good end time. As I understand it, the start time was wrong but something happened that reverted the time correctly in the next rows of logs.
Does the task run on the Default worker, or under a different Windows account? If it's another worker, did you notice a similar journal time discrepancy in other tasks that run on the same worker?
Well we have a doubt. There is a possibility that yesterday our task really took one minute. The other explanation would be that the task, for a reason we dont know, wait for one hour before it really starts.
I had a look to check other tasks doing the same thing and I did not find any. Its run by the default worker so its not related to soft/hard limits.
This is weird. And its always one hour, no more no less.
Update : DBA confirmation : nothing happened on database between 08:30 and 09:30, so the job just waited one hour before doing something.
Ok Now we understand what is happening. It's not obvious at all, you will see.
Imagine you run a task at 8:30 AM. It's failing at 9:30 AM BUT you decided to define 1 automatic rerun for the task. So the tasks reruns automatically at about 9:30.
In this particular case, the log between 8:30 and 9:30 is totally overriden by the log of the rerun. And it's bad for 2 reasons :
You can't understand what happened. You see only one execution one hour after, no clue of what happened in the first hour
You don't have anymore access to the first log so you don't know why it failed at the first place
I think this behaviour should change and logs should be preserved (or at least an option would enable that).