Hi,

I have a job with several tasks. If a certain task fails, the on error meganism will jump back in the task order and runs the tasks again. Than all the tasks are ok.
It has to do with a file download which is not ready sometimes.

So after a while all the tasks are ok and the job is done, but at job level the result is Failed, which is not the case.

Is this the way the job should behave?

Regards,
Erik

---

Hi,

I know this has been discussed back and forth before. If the final Job should be failing or not. We will investigate this some more and get back to you.

thanks you

---

Hi again Erik,

we tried to reproduce this but we couldn't. Here is what we did:

1. We created a File Read Task which read an existing file.
2. We set the on error tab to retry it 3 times with 10 second interval
3. We renamed the file so the file would not be found the first time
4. We ran the Job and the task failed the first time
5. We renamed back the file
6. The Task ran again in retry attempt 1 and Task succeeded along with Job.

Can you reproduce this with our settings?

---

I'll get back on this I think early next week.

Regards
Erik

---

Hi,

I had some time to make the test you suggested.
Result: The task and the job is successful.

The way I configured my job to get the failed result is:

1. wait task of 10 sec
2. read file task, with on error goto wait task

I started by renaming the filename so the 2nd task will fail and will go to the wait task by the on error setting.
During this wait I rename the file to the good name, so the second time the task runs it is ok.
Now the job has the failed status.

Regards,
Erik

---

Let's see if I understand you correctly here.

You have 2 tasks.

1. the wait task - which you run first?
2. the read file task which goes to wait Task.

I assume that you have checked "Run following Tasks in order" in on error tab?

---

Let's see if I understand you correctly here.

You have 2 tasks.

1. the wait task - which you run first?
2. the read file task which goes to wait Task.

I assume that you have checked "Run following Tasks in order" in on error tab?

Correct.

In your situation the file read task will continue (3x) until it reads the file.
In my situation the task fails and jumps back to the wait task and tries is again. This proces will be repeated until the file is red.

Regards,
Erik

---

Then the big question is if Goto Task should reset the current error state as Retry Task do.

In my scenario it is clear that Task x is retried. This means that error status is reset and it tries running again.

In the Goto Task scenario the Task may jump from here to there and it is not clear that Task x, that originally failed, will ever be running again.

So, one idea is to reset error status (if "On error" has been raised). I think it would be hard to track (if it get more complex) if Task x has been run again successfully later. It is easier to reset error state when "goto" another Task.

This idea has consequences. One example could be that Task 2 fails. Goto Task 1 based on "On error". Error state is reset. Task 1 has a condition that exits the job if not met. Then the Job accepted as succesful.

What do you think?

---

This idea has consequences. One example could be that Task 2 fails. Goto Task 1 based on "On error". Error state is reset. Task 1 has a condition that exits the job if not met. Then the Job accepted as succesful.

I userstand, but than task 2 is failed so the job should be failed also, I think.

I think the job result status should look at all the task results and based on that make the job result.

So I think the error state should not be reset with a goto.

I have notifications on my task to get emails when the task fails, so I know.
I think that the status of the job has a higher prio than the task status, based on my notes.

Am I making myself clear?

Regards,
Erik

---

So, you are saying that the error should be removed from a Task if it has been run later with success, for example:

1. Task 1 success
2. Task 2 fail - jump to Task 1
3. Task 1 condition causes jump to Task 3
4. Task 3 condition causes jump to Task 2
5. Task 2 runs with success

Now, the job is success? What I am saying is that VisualCron will never know if your Job really was a success or not when it jumps around between Tasks.

Currently it works like this:

1. if any task has failed the job has failed
2. if a Task is retried and then succesfull the job is succesful
3. if a Task is failing and then uses Goto the job fails

So, an alternative would be to make a list of all Tasks that are being run within a job process. At end, check all results. If Task 2 has failed sometime but later succeded - some time the Job is success. This is a big change and may have consequences. Don't know if there is any better solution.

---

hmm...

I think this has a bigger picture than I think.
Now in my situation I think it is okay that the job has a success status.
But I think I can think of a scenario where I want to know when the task is failing and I want to have my job to have a failed status.

So making the job status based on all the last results of the runned tasks could could give the wrong impression.

hmm again...

We also spoke about repeating tasks in the past. If one of the itteratioins is failing but the last one is ok, I think I want to know that one has failed, so the job should have a failed status.

Did I say hmm already??....

Now it's the case that in the job live period the job fails if a task has failed.
To 'solve' my issue I can change my tasks to repeat itself with the on error tab.

I will discuss this also with my collega's

Regards,
Erik

---

This is a good thread and I am glad you pointed it out. But it is not easy to make changes here as this is "core" functionality and some users may have got used to this behavior. But I agree that you are probably right with that this is the wrong behavior - I just wanted to point out that it is complex to change and may have some side effects.

We'll think about this too and we'll see what we do about this.

---

After talking to a collegue of mine, we think to have the solution:

Have a task where you can set the job status.
Whith this task in your jobs you can make the job fail or succeed.
Any other task after this task can modify the job result as normal.
But placing this task at specific points in your job, you can configure the outcome.

If you like this I'm moving this to the feature requests.

Regards,
Erik

---

Just to put in my 2 cents worth, I think the way VisualCron doe sit now is basically correct - a successful retry should mark the task as a success, and the job should be a success if all of the tasks are successful.

I can see that there are other meanings of job success, but it would be impossible for VisualCron to know what your criteria are unless there were some way to configure it. The thing is, this could get ridiculously complicated when you consider all of the possibilities.

One might offer a checklist of potential options for deciding on job success:
- default (as above, one or more task failures = job failure)
- designating tasks as job-critical with a failure bias (one or more critical task failures = job failure)
- optimistic (one or more task successes = job success) [I don't really see much use for this one, I include it for completeness]
- designating tasks as job-critical with a success bias (one or more critical task successes = job success)
Then there would also need to be a checkbox for each task to indicate whether or not it is a job-critical task.

I could see it being a fair amount of work with a lot of dependencies and unforeseen consequences to implement something like this. Lots of regression testing.

Rebeccah