---
# System prepended metadata

title: Done - Only put executable tasks in queue

---

# Done - Only put executable tasks in queue

## Requirements and questions

- updateMany in MongoDB does not return the list of updated documents
- Do we need a new status ? like Created ? Creating -> Created -> Submitted
- Do we ensure that we do not miss tasks ?
- Do we ensure that we do not duplicate messages ?

T1 - dependencies [R1], counter: 1
T2 - dependencies [R1, R2], counter: 2

## v1

### Algo

- 1/ Find all the tasks with R1 as data dependencies and dependency counter == 1 (and status == created ?)
- Maybe counter <= 1
- 2a/ Decrease counter of all the tasks with R1 as dependency by 1, use $inc as it is atomic on the modified document
- 2b/ Put tasks found in 1/ in the queue, their dependencies are resolved
- 2a and 2b can be done in parallel
- 3/ Update statuses of tasks found in 1/ to submitted

### Case 1

- R2 is available
- 1/ finds none for R2
- 2a/ decreases counter for T2, now counter is 1
- R1 is available
- 1/ finds T1 and T2 for R1
- No issue

### Case 2

- R2 is available
- R1 is available
- 1/ finds none for R2
- 1/ finds T1 for R1
- T2 is not detected as ready, not put in queue

## v2

### Algo


- 1/ Decrease counter of all the tasks with R1 as dependency by 1, use $inc as it is atomic on the modified document
- 2/ Find all the tasks with R1 as data dependencies and dependency counter == 0
- 3/ Put tasks found in 2/ in the queue, their dependencies are resolved
- 4/ Update statuses of tasks found in 1/ to submitted

### Case 1

- P2: R2 is available
- P2: 1/ decreases counter for T2, now counter is 1
- P2: 2/ finds none for R2
- P1: R1 is available
- P1: 1/ decreases counter for T2, now counter is 0
- P1: 1/ decreases counter for T1, now counter is 0
- P1: 2/ finds T1 and T2 for R1
- No issue

### Case 2

- P2: R2 is available
- P1: R1 is available
- P2: 1/ decreases counter for T2, now counter is 1
- P1: 1/ decreases counter for T1, now counter is 0
- P1: 1/ decreases counter for T2, now counter is 0
- P2: 2/ finds none
- P1: 2/ finds T1 and T2 for R1
- No issue

### Case 3

- P2: R2 is available
- P1: R1 is available
- P1: 1/ decreases counter for T1, now counter is 0
- P1: 1/ decreases counter for T2, now counter is 1
- P2: 1/ decreases counter for T2, now counter is 0
- P2: 2/ finds T2 for R2
- P1: 2/ finds T1 and T2 for R1
- Needs acquisition process for putting tasks in queue
- ==> aquisition task per task since there is no findManyAndUpdate
- No way to ask the queue to know if the task is already in the queue

## Hybrid

This approach requires a new agent and a new queue. The agent will check the dependencies of the tasks that are in this queue.
If a task has all its dependencies ready, the task is pushed to its target queue, otherwise, it is ignored.
This can most likely be refined to deduplicate some messages on a best effort basis.


At task creation:
- Iterate over all result dependencies
    - If the result is ready, do nothing more
    - If the result is not ready, add task to its reverse dependencies
    - check again readiness of result. If it's ready, put it to the dependency queue

At task ending:
- Mark all the results of the task ready
- Collect all reverse dependencies of those results
- push all those reverse dependencies in the dependency queue