From 1267aedfd3f6d3fc609a743b2c205d9e78852064 Mon Sep 17 00:00:00 2001 From: Tylan Davis <89618855+tylandavis@users.noreply.github.com> Date: Thu, 7 Nov 2024 12:42:16 -0500 Subject: [PATCH] docs: closes tags properly on jobs queue documentation (#9067) ### What? Fixes a formatting issue that prevents payloadcms.com/docs/beta/jobs-queue/overview from displaying properly. There were a couple `` tags in the `jobs-queue/overview` docs that did not have proper closing `` tags. --- docs/jobs-queue/overview.mdx | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/jobs-queue/overview.mdx b/docs/jobs-queue/overview.mdx index 78d920253..8c50db3ce 100644 --- a/docs/jobs-queue/overview.mdx +++ b/docs/jobs-queue/overview.mdx @@ -21,7 +21,7 @@ There are a few concepts that you should become familiarized with before using P ## Tasks - A "Task" is a function definition that performs business logic and whose input and output are both strongly typed. + A "Task" is a function definition that performs business logic and whose input and output are both strongly typed. You can register Tasks on the Payload config, and then create Jobs or Workflows that use them. Think of Tasks like tidy, isolated "functions that do one specific thing". @@ -46,7 +46,7 @@ Simply add a task to the `jobs.tasks` array in your Payload config. A task consi | `onSuccess` | Function to be executed if the task fails. | | `retries` | Specify the number of times that this step should be retried if it fails. | -The logic for the Task is defined in the `handler` - which can be defined as a function, or a path to a function. The `handler` will run once a worker picks picks up a Job that includes this task. +The logic for the Task is defined in the `handler` - which can be defined as a function, or a path to a function. The `handler` will run once a worker picks picks up a Job that includes this task. It should return an object with an `output` key, which should contain the output of the task as you've defined. @@ -105,7 +105,7 @@ export default buildConfig({ }) ``` -In addition to defining handlers as functions directly provided to your Payload config, you can also pass an _absolute path_ to where the handler is defined. If your task has large dependencies, and you are planning on executing your jobs in a separate process that has access to the filesystem, this could be a handy way to make sure that your Payload + Next.js app remains quick to compile and has minimal dependencies. +In addition to defining handlers as functions directly provided to your Payload config, you can also pass an _absolute path_ to where the handler is defined. If your task has large dependencies, and you are planning on executing your jobs in a separate process that has access to the filesystem, this could be a handy way to make sure that your Payload + Next.js app remains quick to compile and has minimal dependencies. In general, this is an advanced use case. Here's how this would look: @@ -157,7 +157,7 @@ export const createPostHandler: TaskHandler<'createPost'> = async ({ input, job, ## Workflows - A "Workflow" is an optional way to combine multiple tasks together in a way that can be gracefully retried from the point of failure. + A "Workflow" is an optional way to combine multiple tasks together in a way that can be gracefully retried from the point of failure. They're most helpful when you have multiple tasks in a row, and you want to configure each task to be able to be retried if they fail. @@ -220,7 +220,7 @@ export default buildConfig({ }, }) - // Once the prior task completes, it will run a task + // Once the prior task completes, it will run a task // called `updatePost` await runTask({ task: 'updatePost', @@ -311,7 +311,7 @@ export default buildConfig({ Now that we have covered Tasks and Workflows, we can tie them together with a concept called a Job. - Whereas you define Workflows and Tasks, which control your business logic, a Job is an individual instance of either a Task or a Workflow which contains many tasks. + Whereas you define Workflows and Tasks, which control your business logic, a Job is an individual instance of either a Task or a Workflow which contains many tasks. For example, let's say we have a Workflow or Task that describes the logic to sync information from Payload to a third-party system. This is how you'd declare how to sync that info, but it wouldn't do anything on its own. In order to run that task or workflow, you'd create a Job that references the corresponding Task or Workflow. @@ -355,7 +355,7 @@ Now let's talk about how to _run these jobs_. Right now, all we've covered is ho A Queue is a list of jobs that should be executed in order of when they were added. -When you go to run jobs, Payload will query for any jobs that are added to the queue and then run them. By default, all queued jobs are added to the `default` queue. +When you go to run jobs, Payload will query for any jobs that are added to the queue and then run them. By default, all queued jobs are added to the `default` queue. **But, imagine if you wanted to have some jobs that run nightly, and other jobs which should run every five minutes.** @@ -406,11 +406,11 @@ Here's an example of what this file will look like: The configuration above schedules the endpoint `/api/payload-jobs/run` to be invoked every 5 minutes. -The last step will be to secure your `run` endpoint so that only the proper users can invoke the runner. +The last step will be to secure your `run` endpoint so that only the proper users can invoke the runner. To do this, you can set an environment variable on your Vercel project called `CRON_SECRET`, which should be a random string—ideally 16 characters or longer. -Then, you can modify the `access` function for running jobs by ensuring that only Vercel can invoke your runner. +Then, you can modify the `access` function for running jobs by ensuring that only Vercel can invoke your runner. ```ts export default buildConfig({ @@ -421,7 +421,7 @@ export default buildConfig({ // Allow logged in users to execute this endpoint (default) if (req.user) return true - // If there is no logged in user, then check + // If there is no logged in user, then check // for the Vercel Cron secret to be present as an // Authorization header: const authHeader = req.headers.get('authorization'); @@ -450,7 +450,7 @@ await payload.jobs.run({ queue: 'nightly', limit: 100 }) #### Bin script -Finally, you can process jobs via the bin script that comes with Payload out of the box. +Finally, you can process jobs via the bin script that comes with Payload out of the box. ```sh npx payload jobs:run --queue default --limit 10