From 4bbe71729c1ff37e26629f9cee6b76a8e2ef8790 Mon Sep 17 00:00:00 2001
From: Julius Lautz <51713727+julius-lautz@users.noreply.github.com>
Date: Thu, 23 Dec 2021 11:51:59 +0100
Subject: [PATCH] Update 0014-use-choreography-for-task-execution-workflow.md

---
 .../0014-use-choreography-for-task-execution-workflow.md        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/TAPAS-Final/doc/architecture/decisions/0014-use-choreography-for-task-execution-workflow.md b/TAPAS-Final/doc/architecture/decisions/0014-use-choreography-for-task-execution-workflow.md
index 677ab0b..b7f4399 100644
--- a/TAPAS-Final/doc/architecture/decisions/0014-use-choreography-for-task-execution-workflow.md
+++ b/TAPAS-Final/doc/architecture/decisions/0014-use-choreography-for-task-execution-workflow.md
@@ -18,7 +18,7 @@ The reason for why it should be choreographed is that this will optimise the for
 
 Moreover, the workflow should utilise the Front Controller Pattern as this pattern fits the architecture naturally. The tasks in the Task List already have a Status property. This property can be used to keep track of the state of the task within the execution workflow. Moreover, since updating this state is already a part of the architecture, the system will not suffer greatly from the normal drawback of using this pattern (additional state property, increased communication overhead).
 
-Using this pattern will make querying the state trivial since we just need to look up the status of the task in the Task List. Moreover, it makes the Task List a pseudo-orchestrator within our choreography which will reduce the complexity for error handling as much of it can be added to the Task List. Lastly, since the Task List is accessible by the users that created the task, they can then make ultimate decisions for error handling. For example, when no executor has been found for a task (neither internal nor external) then the end user could either delete the task or ask for it to be re-run through the roster and auction house at a later date.
+Using this pattern will make querying the state trivial since we just need to look up the status of the task in the Task List. Moreover, it makes the Task List a pseudo-orchestrator within our choreography which will reduce the complexity for error handling, as much of it can be added to the Task List. Lastly, since the Task List is accessible by the users that created the task, they can then make ultimate decisions for error handling. For example, when no executor has been found for a task (neither internal nor external) then the end user could either delete the task or ask for it to be re-run through the roster and auction house at a later date.
 
 ## Consequences