Breakout workflow pg

docs/encyclopedia/workflow/cron-job.mdx

@@ -0,0 +1,129 @@
+---
+id: cron-job
+title: What is a Temporal Cron Job?
+sidebar_label: Cron Job 
+description: This comprehensive guide provides insights into Temporal Workflows, covering Workflow Definitions in various programming languages, deterministic constraints, handling code changes, and ensuring reliability, durability, and scalability in a Temporal Application, with examples and best practices for Workflow Versioning and development.
+slug: /cron-job
+toc_max_heading_level: 4
+keywords:
+  - cron job
+tags:
+  - Concepts
+  - Workflows
+
+---
+import PrettyImage from '@site/src/components/pretty-image/PrettyImage';
+
+## What is a Temporal Cron Job? {#temporal-cron-job}
+
+:::note
+
+We recommend using [Schedules](#schedule) instead of Cron Jobs.
+Schedules were built to provide a better developer experience, including more configuration options and the ability to update or pause running Schedules.
+
+:::
+
+A Temporal Cron Job is the series of Workflow Executions that occur when a Cron Schedule is provided in the call to spawn a Workflow Execution.
+
+- [How to set a Cron Schedule using the Go SDK](/develop/go/schedules#temporal-cron-jobs)
+- [How to set a Cron Schedule using the Java SDK](/develop/java/schedules#cron-schedule)
+- [How to set a Cron Schedule using the PHP SDK](/develop/php/schedules#temporal-cron-jobs)
+- [How to set a Cron Schedule using the Python SDK](/develop/python/schedules#temporal-cron-jobs)
+- [How to set a Cron Schedule using the TypeScript SDK](/develop/typescript/schedules#temporal-cron-jobs)
+
+<PrettyImage src="/diagrams/temporal-cron-job.svg" title="Temporal Cron Job timeline" />
+
+A Temporal Cron Job is similar to a classic unix cron job.
+Just as a unix cron job accepts a command and a schedule on which to execute that command, a Cron Schedule can be provided with the call to spawn a Workflow Execution.
+If a Cron Schedule is provided, the Temporal Server will spawn an execution for the associated Workflow Type per the schedule.
+
+Each Workflow Execution within the series is considered a Run.
+
+- Each Run receives the same input parameters as the initial Run.
+- Each Run inherits the same Workflow Options as the initial Run.
+
+The Temporal Server spawns the first Workflow Execution in the chain of Runs immediately.
+However, it calculates and applies a backoff (`firstWorkflowTaskBackoff`) so that the first Workflow Task of the Workflow Execution does not get placed into a Task Queue until the scheduled time.
+After each Run Completes, Fails, or reaches the [Workflow Run Timeout](/encyclopedia/detecting-workflow-failures#workflow-run-timeout), the same thing happens: the next run will be created immediately with a new `firstWorkflowTaskBackoff` that is calculated based on the current Server time and the defined Cron Schedule.
+
+The Temporal Server spawns the next Run only after the current Run has Completed, Failed, or has reached the Workflow Run Timeout.
+This means that, if a Retry Policy has also been provided, and a Run Fails or reaches the Workflow Run Timeout, the Run will first be retried per the Retry Policy until the Run Completes or the Retry Policy has been exhausted.
+If the next Run, per the Cron Schedule, is due to spawn while the current Run is still Open (including retries), the Server automatically starts the new Run after the current Run completes successfully.
+The start time for this new Run and the Cron definitions are used to calculate the `firstWorkflowTaskBackoff` that is applied to the new Run.
+
+A [Workflow Execution Timeout](/encyclopedia/detecting-workflow-failures#workflow-execution-timeout) is used to limit how long a Workflow can be executing (have an Open status), including retries and any usage of Continue As New.
+The Cron Schedule runs until the Workflow Execution Timeout is reached or you terminate the Workflow.
+
+<PrettyImage src="/diagrams/temporal-cron-job-failure-with-retry.svg" title="Temporal Cron Job Run Failure with a Retry Policy" />
+
+### Cron Schedules
+
+Cron Schedules are interpreted in UTC time by default.
+
+The Cron Schedule is provided as a string and must follow one of two specifications:
+
+**Classic specification**
+
+This is what the "classic" specification looks like:
+
+```
+┌───────────── minute (0 - 59)
+│ ┌───────────── hour (0 - 23)
+│ │ ┌───────────── day of the month (1 - 31)
+│ │ │ ┌───────────── month (1 - 12)
+│ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday)
+│ │ │ │ │
+│ │ │ │ │
+* * * * *
+```
+
+For example, `15 8 * * *` causes a Workflow Execution to spawn daily at 8:15 AM UTC.
+Use the [crontab guru site](https://crontab.guru/) to test your cron expressions.
+
+### `robfig` predefined schedules and intervals
+
+You can also pass any of the [predefined schedules](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-Predefined_schedules) or [intervals](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-Intervals) described in the [`robfig/cron` documentation](https://pkg.go.dev/github.com/robfig/cron/v3).
+
+```
+| Schedules              | Description                                | Equivalent To |
+| ---------------------- | ------------------------------------------ | ------------- |
+| @yearly (or @annually) | Run once a year, midnight, Jan. 1st        | 0 0 1 1 *     |
+| @monthly               | Run once a month, midnight, first of month | 0 0 1 * *     |
+| @weekly                | Run once a week, midnight between Sat/Sun  | 0 0 * * 0     |
+| @daily (or @midnight)  | Run once a day, midnight                   | 0 0 * * *     |
+| @hourly                | Run once an hour, beginning of hour        | 0 * * * *     |
+```
+
+For example, "@weekly" causes a Workflow Execution to spawn once a week at midnight between Saturday and Sunday.
+
+Intervals just take a string that can be accepted by [time.ParseDuration](http://golang.org/pkg/time/#ParseDuration).
+
+```
+@every <duration>
+```
+
+### Time zones
+
+_This feature only applies in Temporal 1.15 and up_
+
+You can change the time zone that a Cron Schedule is interpreted in by prefixing the specification with `CRON_TZ=America/New_York` (or your [desired time zone from tz](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)). `CRON_TZ=America/New_York 15 8 * * *` therefore spawns a Workflow Execution every day at 8:15 AM New York time, subject to caveats listed below.
+
+Consider that using time zones in production introduces a surprising amount of complexity and failure modes!
+**If at all possible, we recommend specifying Cron Schedules in UTC (the default)**.
+
+If you need to use time zones, here are a few edge cases to keep in mind:
+
+- **Beware Daylight Saving Time:** If a Temporal Cron Job is scheduled around the time when daylight saving time (DST) begins or ends (for example, `30 2 * * *`), **it might run zero, one, or two times in a day**! The Cron library that we use does not do any special handling of DST transitions. Avoid schedules that include times that fall within DST transition periods.
+  - For example, in the US, DST begins at 2 AM. When you "fall back," the clock goes `1:59 … 1:00 … 1:01 … 1:59 … 2:00 … 2:01 AM` and any Cron jobs that fall in that 1 AM hour are fired again. The inverse happens when clocks "spring forward" for DST, and Cron jobs that fall in the 2 AM hour are skipped.
+  - In other time zones like Chile and Iran, DST "spring forward" is at midnight. 11:59 PM is followed by 1 AM, which means `00:00:00` never happens.
+- **Self Hosting note:** If you manage your own Temporal Service, you are responsible for ensuring that it has access to current `tzdata` files. The official Docker images are built with [tzdata](https://docs.w3cub.com/go/time/tzdata/index) installed (provided by Alpine Linux), but ultimately you should be aware of how tzdata is deployed and updated in your infrastructure.
+- **Updating Temporal:** If you use the official Docker images, note that an upgrade of the Temporal Service may include an update to the tzdata files, which may change the meaning of your Cron Schedule. You should be aware of upcoming changes to the definitions of the time zones you use, particularly around daylight saving time start/end dates.
+- **Absolute Time Fixed at Start:** The absolute start time of the next Run is computed and stored in the database when the previous Run completes, and is not recomputed. This means that if you have a Cron Schedule that runs very infrequently, and the definition of the time zone changes between one Run and the next, the Run might happen at the wrong time. For example, `CRON_TZ=America/Los_Angeles 0 12 11 11 *` means "noon in Los Angeles on November 11" (normally not in DST). If at some point the government makes any changes (for example, move the end of DST one week later, or stay on permanent DST year-round), the meaning of that specification changes. In that first year, the Run happens at the wrong time, because it was computed using the older definition.
+
+### How to stop a Temporal Cron Job
+
+A Temporal Cron Job does not stop spawning Runs until it has been Terminated or until the [Workflow Execution Timeout](/encyclopedia/detecting-workflow-failures#workflow-execution-timeout) is reached.
+
+A Cancellation Request affects only the current Run.
+
+Use the Workflow Id in any requests to Cancel or Terminate.

docs/encyclopedia/workflow/dynamic-handler.mdx

@@ -0,0 +1,48 @@
+---
+id: dynamic-handler
+title: What is a Dynamic Handler? 
+sidebar_label: Dynamic Handler
+description: This comprehensive guide provides insights into Temporal Workflows, covering Workflow Definitions in various programming languages, deterministic constraints, handling code changes, and ensuring reliability, durability, and scalability in a Temporal Application, with examples and best practices for Workflow Versioning and development.
+slug: /dynamic-handler
+toc_max_heading_level: 4
+keywords:
+  - dynamic-handler
+tags:
+  - Concepts
+  - Workflows
+
+---
+
+
+## What is a Dynamic Handler? {#dynamic-handler}
+
+Temporal supports Dynamic Workflows, Activities, Signals, and Queries.
+
+:::note
+
+Currently, the Temporal SDKs that support Dynamic Handlers are:
+
+- [Java](/develop/java/message-passing#dynamic-handler)
+- [Python](/develop/python/message-passing#dynamic-handler)
+- [.NET](/develop/dotnet/message-passing#dynamic-handler)
+
+The Go SDK supports Dynamic Signals through the [GetUnhandledSignalNames](https://pkg.go.dev/go.temporal.io/sdk/workflow#GetUnhandledSignalNames) function.
+
+:::
+
+These are unnamed handlers that are invoked if no other statically defined handler with the given name exists.
+
+Dynamic Handlers provide flexibility to handle cases where the names of Workflows, Activities, Signals, or Queries aren't known at run time.
+
+:::caution
+
+Dynamic Handlers should be used judiciously as a fallback mechanism rather than the primary approach.
+Overusing them can lead to maintainability and debugging issues down the line.
+
+Instead, Workflows, Activities, Signals, and Queries should be defined statically whenever possible, with clear names that indicate their purpose.
+Use static definitions as the primary way of structuring your Workflows.
+
+Reserve Dynamic Handlers for cases where the handler names are not known at compile time and need to be looked up dynamically at runtime.
+They are meant to handle edge cases and act as a catch-all, not as the main way of invoking logic.
+
+:::

docs/encyclopedia/workflow/index.mdx

@@ -0,0 +1,36 @@
+---
+id: workflow-deep-dive
+title: Temporal Workflows Deep Dive 
+sidebar_label: Workflows
+description: This comprehensive guide provides insights into Temporal Workflows, covering Workflow Definitions in various programming languages, deterministic constraints, handling code changes, and ensuring reliability, durability, and scalability in a Temporal Application, with examples and best practices for Workflow Versioning and development.
+slug: /workflow-deep-dive
+toc_max_heading_level: 4
+keywords:
+  - child-workflow
+  - child-workflow-executions
+  - continue-as-new
+  - delay-workflow
+  - queries
+  - resets
+  - signals
+  - timeouts
+  - updates
+tags:
+  - Concepts
+  - Workflows
+
+---
+
+# Workflow Deep Dive
+
+In this Workflow guide, you'll find the following information:
+
+- [Workflow Definition](/workflow-definition)
+- [Workflow Execution](/workflow-execution)
+- [Dynamic Handler](/dynamic-handler)
+- [Workflow Schedule](/schedule)
+- [Side Effect](/side-effect)
+- [Start Delay](/start-delay)
+- [Cron Job](/cron-job)
+
+Explore each section to understand how Temporal Workflows operate and how to build them for reliable applications.