GITBOOK-196: fix page references

docs/gitbook/guide/jobs/job-data.md

@@ -4,7 +4,6 @@ Every job can have its own custom data. The data is stored in the **`data`** att
 
 {% tabs %}
 {% tab title="TypeScript" %}
-
 ```typescript
 import { Queue } from 'bullmq';
 
@@ -14,11 +13,9 @@ const job = await myQueue.add('wall', { color: 'red' });
 
 job.data; // { color: 'red' }
 ```
-
 {% endtab %}
 
 {% tab title="Python" %}
-
 ```python
 from bullmq import Queue
 
@@ -28,7 +25,6 @@ job = await queue.add('wall', {'color': 'red'})
 
 job.data # { color: 'red' }
 ```
-
 {% endtab %}
 {% endtabs %}
 
@@ -38,7 +34,6 @@ If you want to change the data after inserting a job, just use the **`updateData
 
 {% tabs %}
 {% tab title="TypeScript" %}
-
 ```typescript
 const job = await Job.create(queue, 'wall', { color: 'red' });
 
@@ -48,11 +43,9 @@ await job.updateData({
 
 job.data; // { color: 'blue' }
 ```
-
 {% endtab %}
 
 {% tab title="Python" %}
-
 ```python
 from bullmq import Queue
 
@@ -63,10 +56,9 @@ job = await queue.add('wall', {'color': 'red'})
 await job.updateData({'color': 'blue'})
 job.data # { color: 'blue' }
 ```
-
 {% endtab %}
 {% endtabs %}
 
 ## Read more:
 
-- 💡 [Update API Reference](https://api.docs.bullmq.io/classes/v5.Job.html#updateData)
+* 💡 [Update Data API Reference](https://api.docs.bullmq.io/classes/v5.Job.html#updateData)

docs/gitbook/guide/jobs/prioritized.md

@@ -25,7 +25,7 @@ await myQueue.add('wall', { color: 'blue' }, { priority: 7 });
 // finally pink.
 ```
 
-If several jobs are added with the same priority value, then the jobs within that priority will be processed in [FIFO (_First in, first out_)](../fifo.md) fashion.
+If several jobs are added with the same priority value, then the jobs within that priority will be processed in [FIFO (_First in, first out_)](fifo.md) fashion.
 
 ## Change priority
 

docs/gitbook/guide/workers/concurrency.md

@@ -1,6 +1,6 @@
 # Concurrency
 
-There are basically two ways to achieve concurrency with BullMQ using Worker instances. You can run a worker with a concurrency factor larger than 1 \(which is the default value\), or you can run several workers in different node processes.
+There are basically two ways to achieve concurrency with BullMQ using Worker instances. You can run a worker with a concurrency factor larger than 1 (which is the default value), or you can run several workers in different node processes.
 
 #### Local Concurrency factor
 
@@ -34,7 +34,7 @@ worker.concurrency = 5;
 The other way to achieve concurrency is to provide multiple workers. This is the recommended way to setup bull anyway since besides providing concurrency it also provides higher availability for your workers. You can easily launch a fleet of workers running in many different machines in order to execute the jobs in parallel in a predictable and robust way.
 
 {% hint style="info" %}
-If you need to achieve a global concurrency of at most 1 job at a time, refer to [Global concurrency](../queues/global-concurrency).
+If you need to achieve a global concurrency of at most 1 job at a time, refer to [Global concurrency](../queues/global-concurrency.md).
 {% endhint %}
 
-You can still \(and it is a perfectly good practice to\) choose a high concurrency factor for every worker, so that the resources of every machine where the worker is running are used more efficiently.
+You can still (and it is a perfectly good practice to) choose a high concurrency factor for every worker, so that the resources of every machine where the worker is running are used more efficiently.

docs/gitbook/guide/workers/graceful-shutdown.md

@@ -3,7 +3,7 @@
 BullMQ supports graceful shutdowns of workers. This is important so that we can minimize stalled jobs when a worker for some reason must be shutdown. But note that even in the event of a "ungraceful shutdown", the stalled mechanism in BullMQ allows for new workers to pick up stalled jobs and continue working on them.
 
 {% hint style="danger" %}
-Prior to BullMQ 2.0, in order for stalled jobs to be picked up by other workers you need to have a [`QueueScheduler`](https://docs.bullmq.io/guide/queuescheduler) class running in the system.
+Prior to BullMQ 2.0, in order for stalled jobs to be picked up by other workers you need to have a [`QueueScheduler`](../queuescheduler.md) class running in the system.
 
 From BullMQ 2.0 and onwards, the `QueueScheduler` is not needed anymore, so the information above is only valid for older versions.
 {% endhint %}
@@ -14,5 +14,4 @@ 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, and 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)\).
-
+The above call will mark the worker as _closing_ so it will not pick up new jobs, and 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)).