docs(gitbook): update v4 references

f11y11 · Jul 7, 2023 · b0adbf8 · b0adbf8
1 parent b47d622
commit b0adbf8
Show file tree

Hide file tree

Showing 62 changed files with 50 additions and 49 deletions.
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...(1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...age (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...age (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...s/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...s/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...age (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png b/...age (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png
diff --git a/...s/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png b/...s/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png
diff --git a/...ssets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...ssets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...ok/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...ok/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...itbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...itbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...ssets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1) (1).png b/...ssets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1) (1).png
diff --git a/...ok/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png b/...ok/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (1).png
diff --git a/...itbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png b/...itbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2).png
diff --git a/...k/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...k/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/...tbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/...tbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (2) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (2) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (2).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (2).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1) (1).png
diff --git a/docs/gitbook/.gitbook/assets/image (1) (1) (1).png b/docs/gitbook/.gitbook/assets/image (1) (1) (1).png
diff --git a/docs/gitbook/README (1).md b/docs/gitbook/README (1).md
@@ -73,7 +73,7 @@ worker.on('failed', (job, err) => {
 There are many other events available, check the [Guide](guide/events.md) or the [API reference](https://api.docs.bullmq.io/) for more information.
 {% endhint %}
 
-Sometimes you need to listen to all the workers events in a given place, for this you need to use a special class [`QueueEvents`](https://api.docs.bullmq.io/classes/QueueEvents.html):
+Sometimes you need to listen to all the workers events in a given place, for this you need to use a special class [`QueueEvents`](https://api.docs.bullmq.io/classes/v4.QueueEvents.html):
 
 ```typescript
 import { QueueEvents } from 'bullmq';

diff --git a/docs/gitbook/bull-3.x-migration/compatibility-class.md b/docs/gitbook/bull-3.x-migration/compatibility-class.md
diff --git a/docs/gitbook/guide/architecture.md b/docs/gitbook/guide/architecture.md
@@ -6,7 +6,7 @@ description: >-
 
 # Architecture
 
-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://api.docs.bullmq.io/classes/Queue.html#add) 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).
+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://api.docs.bullmq.io/classes/v4.Queue.html#add) 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).
 
 <figure><img src="../.gitbook/assets/mermaid-diagram-2023-06-22-093303.png" alt=""><figcaption><p>Lifecycle of a job - Queue</p></figcaption></figure>
 
@@ -18,7 +18,7 @@ Note that priorities go from 0 to 2^21, where 0 is the highest priority, this fo
 
 The next state for a job is the **“active”** state. The active state is represented by a set, and are jobs that are currently being processed, i.e. they are running in the `process` function explained in the previous chapter. A job can be in the active state for an unlimited amount of time until the process is completed or an exception is thrown so that the job will end in either the **“completed”** or the **“failed”** status.
 
-Another way to add a job is by the [`add`](https://api.docs.bullmq.io/classes/FlowProducer.html#add) method on a flow producer instance.
+Another way to add a job is by the [`add`](https://api.docs.bullmq.io/classes/v4.FlowProducer.html#add) method on a flow producer instance.
 
 <figure><img src="../.gitbook/assets/mermaid-diagram-2023-06-22-095138.png" alt=""><figcaption><p>Lifecycle of a job - Flow Producer</p></figcaption></figure>
 

diff --git a/docs/gitbook/guide/events.md b/docs/gitbook/guide/events.md
@@ -89,7 +89,7 @@ await queue.trimEvents(10) # left 10 events
 
 ## Read more:
 
-- 💡 [Queue Events API Reference](https://api.docs.bullmq.io/classes/QueueEvents.html)
-- 💡 [Queue Events Listener API Reference](https://api.docs.bullmq.io/interfaces/QueueEventsListener.html)
-- 💡 [Queue Listener API Reference](https://api.docs.bullmq.io/interfaces/QueueListener.html)
-- 💡 [Worker Listener API Reference](https://api.docs.bullmq.io/interfaces/WorkerListener.html)
+- 💡 [Queue Events API Reference](https://api.docs.bullmq.io/classes/v4.QueueEvents.html)
+- 💡 [Queue Events Listener API Reference](https://api.docs.bullmq.io/interfaces/v4.QueueEventsListener.html)
+- 💡 [Queue Listener API Reference](https://api.docs.bullmq.io/interfaces/v4.QueueListener.html)
+- 💡 [Worker Listener API Reference](https://api.docs.bullmq.io/interfaces/v4.WorkerListener.html)
diff --git a/docs/gitbook/guide/flows/README.md b/docs/gitbook/guide/flows/README.md
@@ -12,7 +12,7 @@ This functionality enables the creation of flows where jobs are the node of tree
 Flows are added to a queue using the "_FlowProducer_" class.
 {% endhint %}
 
-In order to create "flows" you must use the [FlowProducer](https://api.docs.bullmq.io/classes/FlowProducer.html) class. The method [_**add**_](https://api.docs.bullmq.io/classes/FlowProducer.html#add) accepts an object with the following interface:
+In order to create "flows" you must use the [FlowProducer](https://api.docs.bullmq.io/classes/v4.FlowProducer.html) class. The method [_**add**_](https://api.docs.bullmq.io/classes/v4.FlowProducer.html#add) accepts an object with the following interface:
 
 ```typescript
 interface FlowJob {
@@ -199,5 +199,5 @@ await queue.remove(job.id);
 ## Read more:
 
 - 📋 [Divide large jobs using flows](https://blog.taskforce.sh/splitting-heavy-jobs-using-bullmq-flows/)
-- 💡 [FlowProducer API Reference](https://api.docs.bullmq.io/classes/FlowProducer.html)
-- 💡 [Job API Reference](https://api.docs.bullmq.io/classes/Job.html)
+- 💡 [FlowProducer API Reference](https://api.docs.bullmq.io/classes/v4.FlowProducer.html)
+- 💡 [Job API Reference](https://api.docs.bullmq.io/classes/v4.Job.html)
diff --git a/docs/gitbook/guide/flows/adding-bulks.md b/docs/gitbook/guide/flows/adding-bulks.md
@@ -39,4 +39,4 @@ This call can only succeed or fail, and all or none of the jobs will be added.
 
 ## Read more:
 
-- 💡 [Add Bulk API Reference](https://api.docs.bullmq.io/classes/FlowProducer.html#addBulk)
+- 💡 [Add Bulk API Reference](https://api.docs.bullmq.io/classes/v4.FlowProducer.html#addBulk)
diff --git a/docs/gitbook/guide/flows/fail-parent.md b/docs/gitbook/guide/flows/fail-parent.md
@@ -46,4 +46,4 @@ As soon as a _child_ with this option fails, the parent job will be moved to fai
 
 ## Read more:
 
-- 💡 [Add Flow API Reference](https://api.docs.bullmq.io/classes/FlowProducer.html#add)
+- 💡 [Add Flow API Reference](https://api.docs.bullmq.io/classes/v4.FlowProducer.html#add)
diff --git a/docs/gitbook/guide/flows/get-flow-tree.md b/docs/gitbook/guide/flows/get-flow-tree.md
@@ -2,7 +2,7 @@
 
 In some situations, you need to get a job and all of its children, grandchildren and so on.
 
-The pattern to solve this requirement consists on using [getFlow](https://api.docs.bullmq.io/classes/FlowProducer.html#getFlow) method.
+The pattern to solve this requirement consists on using [getFlow](https://api.docs.bullmq.io/classes/v4.FlowProducer.html#getFlow) method.
 
 ```typescript
 const flow = new FlowProducer({ connection });

diff --git a/docs/gitbook/guide/introduction.md b/docs/gitbook/guide/introduction.md
@@ -1,6 +1,6 @@
 # Introduction
 
-BullMQ is based in 4 classes that together can be used to resolve many different problems. These classes are [_**Queue**_](https://api.docs.bullmq.io/classes/Queue.html), [_**Worker**_](https://api.docs.bullmq.io/classes/Worker.html), [_**QueueEvents**_](https://api.docs.bullmq.io/classes/QueueEvents.html) and [_**FlowProducer**_](https://api.docs.bullmq.io/classes/FlowProducer.html).
+BullMQ is based in 4 classes that together can be used to resolve many different problems. These classes are [_**Queue**_](https://api.docs.bullmq.io/classes/v4.Queue.html), [_**Worker**_](https://api.docs.bullmq.io/classes/v4.Worker.html), [_**QueueEvents**_](https://api.docs.bullmq.io/classes/v4.QueueEvents.html) and [_**FlowProducer**_](https://api.docs.bullmq.io/classes/v4.FlowProducer.html).
 
 The first class you should know about is the _Queue_ class. This class represents a queue and can be used for adding _**jobs**_ to the queue as well as some other basic manipulation such as pausing, cleaning or getting data from the queue.
 

diff --git a/docs/gitbook/guide/jobs/README.md b/docs/gitbook/guide/jobs/README.md
@@ -6,4 +6,4 @@ An important thing to consider is that you can mix the different job types in th
 
 ## Read more:
 
-- 💡 [Job API Reference](https://api.docs.bullmq.io/classes/Job.html)
+- 💡 [Job API Reference](https://api.docs.bullmq.io/classes/v4.Job.html)
diff --git a/docs/gitbook/guide/jobs/delayed.md b/docs/gitbook/guide/jobs/delayed.md
@@ -42,4 +42,4 @@ Take in count that your job must be into delayed state when you change the delay
 
 ## Read more:
 
-- 💡 [Change Delay API Reference](https://api.docs.bullmq.io/classes/Job.html#changeDelay)
+- 💡 [Change Delay API Reference](https://api.docs.bullmq.io/classes/v4.Job.html#changeDelay)
diff --git a/docs/gitbook/guide/jobs/getters.md b/docs/gitbook/guide/jobs/getters.md
@@ -18,7 +18,7 @@ const counts = await myQueue.getJobCounts('wait', 'completed', 'failed');
 // Returns an object like this { wait: number, completed: number, failed: number }
 ```
 
-The available status are: _completed, failed, delayed, active, wait, paused_ and _repeat._
+The available status are: _completed, failed, delayed, active, wait, waiting-children, prioritized, _paused_ and _repeat._
 
 #### Get Jobs
 
@@ -32,5 +32,5 @@ const completed = await myQueue.getJobs(['completed'], 0, 100, true);
 
 ## Read more:
 
-* 💡 [Get Job Counts API Reference](https://api.docs.bullmq.io/classes/Queue.html#getJobCounts)
-* 💡 [Get Jobs API Reference](https://api.docs.bullmq.io/classes/Queue.html#getJobs)
+* 💡 [Get Job Counts API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#getJobCounts)
+* 💡 [Get Jobs API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#getJobs)
diff --git a/docs/gitbook/guide/jobs/job-data.md b/docs/gitbook/guide/jobs/job-data.md
@@ -69,4 +69,4 @@ job.data # { color: 'blue' }
 
 ## Read more:
 
-- 💡 [Update API Reference](https://api.docs.bullmq.io/classes/Job.html#updateData)
+- 💡 [Update API Reference](https://api.docs.bullmq.io/classes/v4.Job.html#updateData)
diff --git a/docs/gitbook/guide/jobs/job-ids.md b/docs/gitbook/guide/jobs/job-ids.md
@@ -24,4 +24,4 @@ await myQueue.add(
 
 ## Read more:
 
-- 💡 [Duplicated Event Reference](https://api.docs.bullmq.io/interfaces/QueueEventsListener.html#duplicated)
+- 💡 [Duplicated Event Reference](https://api.docs.bullmq.io/interfaces/v4.QueueEventsListener.html#duplicated)
diff --git a/docs/gitbook/guide/jobs/prioritized.md b/docs/gitbook/guide/jobs/prioritized.md
@@ -49,4 +49,4 @@ await job.changePriority({
 
 ## Read more:
 
-- 💡 [Change Priority API Reference](https://api.docs.bullmq.io/classes/Job.html#changePriority)
+- 💡 [Change Priority API Reference](https://api.docs.bullmq.io/classes/v4.Job.html#changePriority)
diff --git a/docs/gitbook/guide/jobs/removing-job.md b/docs/gitbook/guide/jobs/removing-job.md
@@ -53,4 +53,4 @@ In case one of the children is locked, it will stop the deletion process.
 
 ### Read more:
 
-* 💡 [Remove API Reference](https://api.docs.bullmq.io/classes/Job.html#remove)
+* 💡 [Remove API Reference](https://api.docs.bullmq.io/classes/v4.Job.html#remove)
diff --git a/docs/gitbook/guide/jobs/repeatable.md b/docs/gitbook/guide/jobs/repeatable.md
@@ -2,7 +2,7 @@ There is a special type of _meta_ job called **repeatable**. These jobs are spec
 
 Adding a job with the `repeat` option set will actually do two things immediately: create a Repeatable Job configuration, and schedule a regular delayed job for the job's first run. This first run will be scheduled "on the hour", that is if you create a job that repeats every 15 minutes at 4:07, the job will first run at 4:15, then 4:30, and so on.
 
-The Repeatable Job configuration is not a job, so it will not show up in methods like `getJobs()`. To manage Repeatable Job configurations, use [`getRepeatableJobs()`](https://api.docs.bullmq.io/classes/Queue.html#getRepeatableJobs) and similar. This also means repeated jobs do **not** participate in evaluating `jobId` uniqueness - that is, a non-repeatable job can have the same `jobId` as a Repeatable Job configuration, and two Repeatable Job configurations can have the same `jobId` as long as they have different repeat options.
+The Repeatable Job configuration is not a job, so it will not show up in methods like `getJobs()`. To manage Repeatable Job configurations, use [`getRepeatableJobs()`](https://api.docs.bullmq.io/classes/v4.Queue.html#getRepeatableJobs) and similar. This also means repeated jobs do **not** participate in evaluating `jobId` uniqueness - that is, a non-repeatable job can have the same `jobId` as a Repeatable Job configuration, and two Repeatable Job configurations can have the same `jobId` as long as they have different repeat options.
 
 Every time a repeatable job is picked up for processing, the next repeatable job is added to the queue with a proper delay. Repeatable jobs are thus nothing more than delayed jobs that are added to the queue according to some settings.
 
@@ -50,9 +50,9 @@ There are some important considerations regarding repeatable jobs:
 
 - Bull is smart enough not to add the same repeatable job if the repeat options are the same.
 - If there are no workers running, repeatable jobs will not accumulate next time a worker is online.
-- repeatable jobs can be removed using the [removeRepeatable](https://api.docs.bullmq.io/classes/Queue.html#removeRepeatable) method or [removeRepeatableByKey](https://api.docs.bullmq.io/classes/Queue.html#removeRepeatableByKey).
+- repeatable jobs can be removed using the [removeRepeatable](https://api.docs.bullmq.io/classes/v4.Queue.html#removeRepeatable) method or [removeRepeatableByKey](https://api.docs.bullmq.io/classes/v4.Queue.html#removeRepeatableByKey).
 
-All repeatable jobs have a repeatable job key that holds some metadata of the repeatable job itself. It is possible to retrieve all the current repeatable jobs in the queue calling [getRepeatableJobs](https://api.docs.bullmq.io/classes/Queue.html#getRepeatableJobs):
+All repeatable jobs have a repeatable job key that holds some metadata of the repeatable job itself. It is possible to retrieve all the current repeatable jobs in the queue calling [getRepeatableJobs](https://api.docs.bullmq.io/classes/v4.Queue.html#getRepeatableJobs):
 
 ```typescript
 import { Queue } from 'bullmq';
@@ -177,4 +177,4 @@ Repeat strategy function receives an optional jobName parameter as the 3rd one.
 
 ## Read more:
 
-- 💡 [Repeat Strategy API Reference](https://api.docs.bullmq.io/types/RepeatStrategy.html)
+- 💡 [Repeat Strategy API Reference](https://api.docs.bullmq.io/types/v4.RepeatStrategy.html)
diff --git a/docs/gitbook/guide/jobs/stalled.md b/docs/gitbook/guide/jobs/stalled.md
@@ -38,4 +38,4 @@ export default = (job) => {
 
 ## Read more:
 
-* 💡 [Queue Scheduler API Reference](https://github.com/taskforcesh/bullmq/blob/v1.91.1/docs/gitbook/api/bullmq.queuescheduler.md)
+* 💡 [Queue Scheduler API Reference](https://api.docs.bullmq.io/classes/v1.QueueScheduler.html)
diff --git a/docs/gitbook/guide/queues/README.md b/docs/gitbook/guide/queues/README.md
@@ -14,7 +14,7 @@ See [Connections](../connections.md) for details on how to pass Redis details to
 
 When you instance a Queue, BullMQ will just _upsert_ a small "meta-key", so if the queue existed before it will just pick it up and you can continue adding jobs to it.
 
-The most important method is probably the [_**add**_](https://api.docs.bullmq.io/classes/Queue.html#add) method. This method allows you to add jobs to the queue in different fashions:
+The most important method is probably the [_**add**_](https://api.docs.bullmq.io/classes/v4.Queue.html#add) method. This method allows you to add jobs to the queue in different fashions:
 
 ```typescript
 await queue.add('paint', { color: 'red' });
@@ -42,4 +42,4 @@ There are many other options available such as priorities, backoff settings, lif
 
 ## Read more:
 
-* 💡 [Queue API Reference](https://api.docs.bullmq.io/classes/Queue.html)
+* 💡 [Queue API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html)
diff --git a/docs/gitbook/guide/queues/adding-bulks.md b/docs/gitbook/guide/queues/adding-bulks.md
@@ -18,4 +18,4 @@ This call can only succeed or fail, and all or none of the jobs will be added.
 
 ## Read more:
 
-- 💡 [Add Bulk API Reference](https://api.docs.bullmq.io/classes/Queue.html#addBulk)
+- 💡 [Add Bulk API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#addBulk)
diff --git a/docs/gitbook/guide/queues/auto-removal-of-jobs.md b/docs/gitbook/guide/queues/auto-removal-of-jobs.md
@@ -40,7 +40,7 @@ new Worker('test', async job => {}, {
 
 ### Keep jobs based on their age
 
-Another possibility is to keep jobs up to a certain age. The "removeOn" option accepts a "[KeepJobs](https://api.docs.bullmq.io/interfaces/KeepJobs.html)" object, that includes an "age" and a "count" fields. The age is used to specify how old jobs to keep (in seconds), and the count can be used to limit the total amount to keep. The count option is useful in cases we get an unexpected amount of jobs in a very short time, in this case we may just want to limit to a certain amount to avoid running out of memory.
+Another possibility is to keep jobs up to a certain age. The "removeOn" option accepts a "[KeepJobs](https://api.docs.bullmq.io/interfaces/v4.KeepJobs.html)" object, that includes an "age" and a "count" fields. The age is used to specify how old jobs to keep (in seconds), and the count can be used to limit the total amount to keep. The count option is useful in cases we get an unexpected amount of jobs in a very short time, in this case we may just want to limit to a certain amount to avoid running out of memory.
 
 ```typescript
 await myQueue.add(
@@ -83,4 +83,4 @@ One of the strategies to implement idempotence with BullMQ is to use unique job
 
 ## Read more:
 
-- 💡 [Duplicated Event Reference](https://api.docs.bullmq.io/interfaces/QueueEventsListener.html#duplicated)
+- 💡 [Duplicated Event Reference](https://api.docs.bullmq.io/interfaces/v4.QueueEventsListener.html#duplicated)
diff --git a/docs/gitbook/guide/queues/removing-jobs.md b/docs/gitbook/guide/queues/removing-jobs.md
@@ -56,6 +56,6 @@ have pending children in other queues, or just moved to wait.
 
 ## Read more:
 
-- 💡 [Drain API Reference](https://api.docs.bullmq.io/classes/Queue.html#drain)
-- 💡 [Clean API Reference](https://api.docs.bullmq.io/classes/Queue.html#clean)
-- 💡 [Obliterate API Reference](https://api.docs.bullmq.io/classes/Queue.html#obliterate)
+- 💡 [Drain API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#drain)
+- 💡 [Clean API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#clean)
+- 💡 [Obliterate API Reference](https://api.docs.bullmq.io/classes/v4.Queue.html#obliterate)
diff --git a/docs/gitbook/guide/queuescheduler.md b/docs/gitbook/guide/queuescheduler.md
@@ -29,4 +29,4 @@ It is ok to have as many QueueScheduler instances as you want, just keep in mind
 
 ## Read more:
 
-* 💡 [Queue Scheduler API Reference](https://github.com/taskforcesh/bullmq/blob/v1.91.1/docs/gitbook/api/bullmq.queuescheduler.md)
+* 💡 [Queue Scheduler API Reference](https://api.docs.bullmq.io/classes/v1.QueueScheduler.html)
diff --git a/docs/gitbook/guide/rate-limiting.md b/docs/gitbook/guide/rate-limiting.md
@@ -86,4 +86,4 @@ const worker = new Worker(
 
 ## Read more:
 
-- 💡 [Rate Limit API Reference](https://api.docs.bullmq.io/classes/Worker.html#rateLimit)
+- 💡 [Rate Limit API Reference](https://api.docs.bullmq.io/classes/v4.Worker.html#rateLimit)
diff --git a/docs/gitbook/guide/retrying-failing-jobs.md b/docs/gitbook/guide/retrying-failing-jobs.md
@@ -15,7 +15,7 @@ In general, as a best practice, it is better to always throw Error objects. Ther
 
 When a processor throws an exception, the worker will catch it and move the job to the failed set. Depending on your [Queue settings](https://docs.bullmq.io/guide/queues/auto-removal-of-jobs), the job may stay in the failed set forever, or it could be automatically removed.&#x20;
 
-Often it is desirable to automatically retry failed jobs so that we do not give up until a certain amount of retries have failed. In order to activate automatic job retries you should use the [attempts](https://api.docs.bullmq.io/interfaces/BaseJobOptions.html#attempts) setting with a value larger than 1 (see the examples below).
+Often it is desirable to automatically retry failed jobs so that we do not give up until a certain amount of retries have failed. In order to activate automatic job retries you should use the [attempts](https://api.docs.bullmq.io/interfaces/v4.BaseJobOptions.html#attempts) setting with a value larger than 1 (see the examples below).
 
 BullMQ supports retries of failed jobs using back-off functions. It is possible to use the **built-in** backoff functions or provide **custom** ones. If you do not specify a back-off function, the jobs will be retried without delay as soon as they fail.
 

diff --git a/docs/gitbook/guide/workers/README.md b/docs/gitbook/guide/workers/README.md
@@ -119,5 +119,5 @@ const worker = new Worker<MyData, MyReturn>(queueName, async (job: Job) => {});
 
 ## Read more:
 
-* 💡 [Worker API Reference](https://api.docs.bullmq.io/classes/Worker.html)
-* 💡 [Queue Events API Reference](https://api.docs.bullmq.io/classes/QueueEvents.html)
+* 💡 [Worker API Reference](https://api.docs.bullmq.io/classes/v4.Worker.html)
+* 💡 [Queue Events API Reference](https://api.docs.bullmq.io/classes/v4.QueueEvents.html)
diff --git a/docs/gitbook/guide/workers/graceful-shutdown.md b/docs/gitbook/guide/workers/graceful-shutdown.md
@@ -16,4 +16,5 @@ In order to perform a shutdown just call the _**close**_ method:
 await worker.close();
 ```
 
-The above call will mark the worker as _closing_ so it will not pick up new jobs, at the same time it will wait for all the current jobs to be processed \(or failed\). This call will not timeout by itself, so you should make sure that your jobs finalize in a timely manner. If this call fails for some reason or it is not able to complete, the pending jobs will be marked as stalled and processed by other workers \(if correct stalled options are configured on the [QueueScheduler](https://api.docs.bullmq.io/interfaces/QueueSchedulerOptions.html)\).
+The above call will mark the worker as _closing_ so it will not pick up new jobs, at the same time it will wait for all the current jobs to be processed \(or failed\). This call will not timeout by itself, so you should make sure that your jobs finalize in a timely manner. If this call fails for some reason or it is not able to complete, the pending jobs will be marked as stalled and processed by other workers \(if correct stalled options are configured on the [QueueScheduler](https://api.docs.bullmq.io/interfaces/v1.QueueSchedulerOptions.html)\).
+