docs(architecture): replace state diagram

docs/gitbook/guide/architecture.md

@@ -8,7 +8,23 @@ description: >-
 
 In order to use the full potential of Bull queues, it is important to understand the lifecycle of a job. From the moment a producer calls the [`add`](https://github.com/taskforcesh/bullmq/blob/master/docs/gitbook/api/bullmq.queue.add.md) method on a queue instance, a job enters a lifecycle where it will be in different states, until its completion or failure \(although technically a failed job could be retried and get a new lifecycle\).
 
-![Lifecycle of a job](../.gitbook/assets/image%20%281%29%20%281%29%20%281%29%20%281%29.png)
+```mermaid
+stateDiagram-v2
+state ja <<fork>>
+state jf <<fork>>
+    [*] --> ja : job added
+    ja --> wait
+    ja --> delayed
+    wait --> active
+    wait --> delayed : when it's in rate limit
+    delayed --> wait
+    active --> completed
+    active --> failed
+    completed --> jf
+    failed --> jf
+    active --> delayed : when error and auto retry is enabled
+    jf --> [*] : job finished
+```
 
 When a job is added to a queue it can be in one of two states, it can either be in the “wait” status, which is, in fact, a waiting list, where all jobs must enter before they can be processed, or it can be in a “delayed” status: a delayed status implies that the job is waiting for some timeout or to be promoted for being processed, however, a delayed job will not be processed directly, instead it will be placed at the beginning of the waiting list and processed as soon as a worker is idle.