Task does not have a way to store the result

[ysavourel]

The Task object has a progress property that indicates how the task is progressing, but there is no place to set the result of the task.

I can think of two ways to address that:

Have a status property that covers the progress and the result, something like:

• pending
• in-progress
• paused
• canceled
• completed
• failed
• completed-with-warning

Or have two distinct fields: one for the progress, one for the result

• success
• error
• warning
• null (no result yet)

It would be also probably useful to have a spot to store additional information about the result: an error message, or a list of warnings. Otherwise, I'm not sure how we can convey additional information about the issues the task ran into.

Or maybe I'm missing something and we do have some way to retrieve the result of the tasks.

[Alino]

I agree more with the first variant (Task.status) And for an additional error/warning message, we can create a new Task attribute note (Task.note) where the asignee or job manager or whoever can add a note about a Task.

here is the current description for Task statuses

Task can have these statuses:

pending - the Task has been created, and it's pending to be reviewed and assigned to 
in progress - the Task has been assigned to someone and is being worked 

paused - the Task went from in progress, to paused, because something is blocking the Task, or the assignee has other 

canceled - someone did cancel this 

finished - the work on this Task is done and deliverableLocation is filled with a path to deliverable.

what is the difference between failed and canceled? do we want to rename finished to completed?

[ysavourel]

canceled would be when a user cancel the task. failed would be when the task could not be completed because an error occurred. finished would be replaced by completed, completed-with-warning and failed.

I don't have strong feeling about the names themselves, but I think it's important that we have the concepts.

The note field for the result would be fine, but it would not be practical to rely on parsing that field to know if the result was a success, an error, or at least one warning.

[Alino]

so canceled will be triggered by the user in the user interface. and failed would be triggered by? What is an example when a Task could fail?

I don't have strong feelings about the naming here either, I agree that we can change finished to completed.

So would you like to have special fields for warnings, errors? My thinking was if a Task is failed then we know there was an error and what is in the note, will be more detailed information about that. If the Task is completed-with-warning then we know there is a warning inside note.

But on the other hand, let's say that the note could be filled at the Task creation. Later an error or warning occurs, then how should the already existing text be handled? So we might want to create separate fields errorMessage, warningMessage

[ysavourel]

What is an example when a Task could fail?

Whenever the process have an error: For example the asset file contains a syntax error and the processor cannot read it.

So would you like to have special fields for warnings, errors?

No, a notes field would be enough. I was just saying that I didn't have strong feeling about the names for failed, completed etc. (they could be named differently if people want to) what is important is that their concepts are covered in status (and well described). The scenario failed and completed-with-warning you described is fine with me.

[Alino]

How will the failed status get triggered? By TAPICC? Do we want some validation functions for Asset files? Or by the external system automatically? Or manually by the user in UI?

[ysavourel]

How will the failed status get triggered? By TAPICC? Do we want some validation functions for Asset files? Or by the external system automatically? Or manually by the user in UI?

The failed status would be set by the application implementing the TAPICC interface, whenever applying a given task to a given asset fails. No matter how many validation functions we have anywhere, a task may always fail. It sounds like you are expecting tasks to never fail.

[Alino]

I am trying to understand the difference between failed and canceled.

My initial thinking was that theoretically a failed Task can be perceived as one of the reasons for Task cancelation. (Task was canceled because it failed due an error).

But I guess you want to separate them to be able to see easier if a Task has a technical reason to fail for example due to validation errors. Is that correct?

EDIT: this separation could be also achieved if we dump 'failed' and keep only 'canceled' and we add field 'errorMessage'. So if a Task is 'canceled' and errorMessage contains text, then it can be considered as a Task which was canceled due to the error in the errorMessage (in other words a failing Task).

---

How can an error occur in a Task? You mention that "processor cannot read it" My assumption how that would work is:

• A new Asset (with syntax errors) is created with 5 Tasks assigned to user X.
• The default Task.status is set to 'pending'

What needs to happen now, so that the Tasks.status becomes 'failed'?

• I assume the external system tries to retrieve the Asset and somehow process it.
• If it fails to process that file, then it automatically sets all Tasks of that Asset as 'failed' and sets each Task.note with the error message.

is my scenario valid? EDIT: my scenario is probably not valid, because I guess the Asset is uploaded from the external system and that system should validate the Asset file before uploading it? So I don't know what triggers the validation / syntax error.

[ysavourel]

I see what you mean now. But yes, I think it's important to distinguish at the status level a task that has been canceled on purpose by a user from a task that has not been completed because an error occurred.

[Alino]

added to swagger https://github.com/GALAglobal/TAPICC-API-implementation/commit/be5530f8b16f4f130a7581ddc9b083214043c789