refactor: delete of XXX_FETCHED

oqtopus-team · Oct 9, 2024 · a979a5d · a979a5d
1 parent 5633bc5
commit a979a5d
Showing 1 changed file with 8 additions and 32 deletions.
diff --git a/docs/en/architecture/sequence_diagram.md b/docs/en/architecture/sequence_diagram.md
@@ -28,11 +28,7 @@ sequenceDiagram
     User->>Cloud: GET /tasks/<task ID-1>/status
     Cloud-->>User: HTTP 200 OK { "taskId": <task ID-1>, "status": "QUEUED" }
 
-    Provider->>Cloud: GET /internal/tasks/unfetched?deviceId=SC&status=QUEUED
-    Note over Cloud: The statuses of fetched tasks are updated to QUEUED_FETCHED.
-    Cloud-->>Provider: HTTP 200 OK {[ {"taskId": <task ID-1>, ... }, { "taskId: <task ID-2>, ... }, ... ]}
-
-    Note over Provider: Provider starts execution of the fetched tasks<br>and sends requests to update their statuses to RUNNING.
+    Note over Provider: Provider starts execution of the tasks<br>and sends requests to update their statuses to RUNNING.
     Provider->>Cloud: PATCH /internal/tasks/<task ID-1> { "status": "RUNNING" }
     Note over Cloud: The task status is updated to RUNNING.
     Cloud-->>Provider: HTTP 200 OK
@@ -56,14 +52,9 @@ sequenceDiagram
     Cloud-->>User: HTTP 200 OK { "taskId": <task ID-1>, "status": "SUCCESS", "result": ... }
 ```
 
-Provider periodically repeats the process of fetching tasks, executing the tasks, and sending the results.
+Provider periodically repeats the process of executing the tasks and sending the results.
 The above diagram shows one iteration of the repeated process.
 
-> [!NOTE]
-> Cloud exposes the information on whether a task is fetched (i.e., whether the status has the suffix of _FETCHED) to Provider only; Cloud does not expose it to User.
-> For example, if User requests information of a task in QUEUED_FETCHED status from Cloud, the value of the task status is QUEUED in the response from Cloud.
-> In contrast, the value of the task status is QUEUED_FETCHED in a response to Provider.
-
 ### Data in the DB at Each Time Point
 
 The followings show sample data in the DB at each point in the sequence diagram,
@@ -73,9 +64,6 @@ The numbers below correspond to the circled numbers in the sequence diagram.
 - (2)
   - tasks table: [success-case-tasks-02.csv](../../sample/architecture/success-case-tasks-02.csv)
   - results table: no data
-- (6)
-  - tasks table: [success-case-tasks-06.csv](../../sample/architecture/success-case-tasks-06.csv)
-  - results table: no data
 - (10)
   - tasks table: [success-case-tasks-10.csv](../../sample/architecture/success-case-tasks-10.csv)
   - results table: no data
@@ -104,11 +92,7 @@ sequenceDiagram
     User->>Cloud: GET /tasks/<task ID-1>/status
     Cloud-->>User: HTTP 200 OK { "taskId": <task ID-1>, "status": "QUEUED" }
 
-    Provider->>Cloud: GET /internal/tasks/unfetched?deviceId=SVSim&status=QUEUED
-    Note over Cloud: The statuses of fetched tasks are updated to QUEUED_FETCHED.
-    Cloud-->>Provider: HTTP 200 OK {[ {"taskId": <task ID-1>, ... }, { "taskId: <task ID-2>, ... }, ... ]}
-
-    Note over Provider: Provider starts execution of the fetched tasks<br>and sends requests to update their statuses to RUNNING.
+    Note over Provider: Provider starts execution of the tasks<br>and sends requests to update their statuses to RUNNING.
     Provider->>Cloud: PATCH /internal/tasks/<task ID-1> { "status": "RUNNING" }
     Note over Cloud: The task status is updated to RUNNING.
     Cloud-->>Provider: HTTP 200 OK
@@ -149,7 +133,7 @@ The numbers below correspond to the circled numbers in the sequence diagram.
 ## Sequence of Task Cancellation
 
 The following shows a sequence of task cancellation,
-where User tries to cancel a task when the task in the DB is in QUEUED_FETCHED status.
+where User tries to cancel a task.
 
 ```mermaid
 sequenceDiagram
@@ -166,11 +150,7 @@ sequenceDiagram
     User->>Cloud: GET /tasks/<task ID-1>/status
     Cloud-->>User: HTTP 200 OK { "taskId": <task ID-1>, "status": "CANCELLING" }
 
-    Provider->>Cloud: GET /internal/tasks/unfetched?deviceId=SVSim&status=CANCELLING
-    Note over Cloud: The statuses of fetched tasks are updated to CANCELLING_FETCHED.
-    Cloud-->>Provider: HTTP 200 OK {[ {"taskId": <task ID-1>, ... }, { "taskId: <task ID-2>, ... }, ... ]}
-
-    Note over Provider: Provider tries to cancel the executions of the fetched tasks.
+    Note over Provider: Provider tries to cancel the executions of the tasks.
     Note over Provider: The execution of the task <task ID-1> is successfully cancelled.
     Provider->>Cloud: POST /internal/results { "taskId": <task ID-1>, "status": "CANCELLED", "reason": ... }
 
@@ -184,13 +164,13 @@ sequenceDiagram
     Cloud-->>User: HTTP 200 OK { "taskId": <task ID-1>, "status": "CANCELLED", "reason": ... }
 ```
 
-Provider periodically repeats the process of fetching cancel requests (i.e., tasks in CANCELLING status), cancelling task executions, and sending the cancellation results.
+Provider periodically repeats the process of cancelling task executions and sending the cancellation results.
 The above diagram shows one iteration of the repeated process.
 
 ### Data in the DB at Each Time Point
 
 The followings show sample data in the DB at each point in the sequence diagram,
-where there is one cancellation request to the endpoint `/tasks/sampling/{taskId}/cancel` when the task in the DB is QUEUED_FETCHED status.
+where there is one cancellation request to the endpoint `/tasks/sampling/{taskId}/cancel`.
 The numbers below correspond to the circled numbers in the sequence diagram.
 
 - (1)
@@ -199,14 +179,10 @@ The numbers below correspond to the circled numbers in the sequence diagram.
 - (2)
   - tasks table: [cancel-case-tasks-02.csv](../../sample/architecture/cancel-case-tasks-02.csv)
   - results table: no data
-- (6)
-  - tasks table: [cancel-case-tasks-06.csv](../../sample/architecture/cancel-case-tasks-06.csv)
-  - results table: no data
 - (8)
   - tasks table: [cancel-case-tasks-08.csv](../../sample/architecture/cancel-case-tasks-08.csv)
   - results table: [cancel-case-results-08.csv](../../sample/architecture/cancel-case-results-08.csv)
 
 > [!NOTE]
-> If the task is in QUEUED status (i.e., before Provider fetches the task) at (1), Cloud immediately changes the task status to CANCELLED.
+> If the task is in QUEUED status at (1), Cloud immediately changes the task status to CANCELLED.
 > It means the task state transitions from (1) to (8) directly.
-> In this case, the task is never fetched by Provider.