### Start and Get Onboarding Workflow

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Starters.md

This endpoint allows you to initiate an onboarding workflow and then check its execution status.

```APIDOC
## PUT /api/v1/onboardings/{onboardingId}

### Description
Starts an onboarding workflow with the specified ID and value.

### Method
PUT

### Endpoint
`/api/v1/onboardings/{onboardingId}`

### Parameters
#### Path Parameters
- **onboardingId** (string) - Required - The unique identifier for the onboarding process.

#### Query Parameters
- **value** (string) - Required - The value to be associated with the onboarding process.

### Request Example
```json
{
  "example": "http PUT http://{HOSTNAME}/api/v1/onboardings/onboarding-123 value=some-value"
}
```

### Response
#### Success Response (200)
- **status** (string) - The current status of the onboarding workflow.
- **workflowId** (string) - The ID of the started workflow.

#### Response Example
```json
{
  "example": "Workflow started successfully"
}
```

## GET /api/v1/onboardings/{onboardingId}

### Description
Retrieves the input parameters and execution status of a specific onboarding workflow.

### Method
GET

### Endpoint
`/api/v1/onboardings/{onboardingId}`

### Parameters
#### Path Parameters
- **onboardingId** (string) - Required - The unique identifier for the onboarding process.

### Request Example
```json
{
  "example": "http GET http://{HOSTNAME}/api/v1/onboardings/onboarding-123"
}
```

### Response
#### Success Response (200)
- **inputParameters** (object) - The input parameters used for the workflow.
- **executionStatus** (string) - The current execution status of the workflow.

#### Response Example
```json
{
  "example": {
    "inputParameters": {
      "value": "some-value"
    },
    "executionStatus": "RUNNING"
  }
}
```
```

--------------------------------

### Start Workflow with Options - Java

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Demonstrates how to start a Temporal workflow using the Java SDK with comprehensive options. This includes configuring the Workflow ID, Task Queue, conflict policies, and execution timeouts for idempotency and control.

```java
import io.temporal.client.WorkflowClient;
import io.temporal.client.WorkflowOptions;
import io.temporal.serviceclient.WorkflowServiceStubs;
import io.temporal.api.common.v1.WorkflowIdConflictPolicy;
import io.temporal.api.common.v1.WorkflowIdReusePolicy;
import java.time.Duration;

// Connect to Temporal service
WorkflowServiceStubs service = WorkflowServiceStubs.newLocalServiceStubs();
WorkflowClient client = WorkflowClient.newInstance(service);

// Configure workflow options with business-meaningful ID
WorkflowOptions options = WorkflowOptions.newBuilder()
    .setWorkflowId("order-processing-ORD-2024-001")  // Business-domain ID for idempotency
    .setTaskQueue("order-processing")                 // Route to appropriate workers
    .setWorkflowIdConflictPolicy(WorkflowIdConflictPolicy.USE_EXISTING)  // Idempotent starts
    .setWorkflowIdReusePolicy(WorkflowIdReusePolicy.REJECT_DUPLICATE)    // Prevent duplicates
    .setWorkflowExecutionTimeout(Duration.ofDays(45))  // Safety net timeout
    .build();

// Create typed workflow stub and start execution
OrderWorkflow workflow = client.newWorkflowStub(OrderWorkflow.class, options);
WorkflowExecution execution = WorkflowClient.start(workflow::processOrder, orderData);

// Output: Workflow started with ID: order-processing-ORD-2024-001
System.out.println("Workflow started with ID: " + execution.getWorkflowId());
```

--------------------------------

### Get Entity Onboarding Status via HTTP GET

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Starters.md

Retrieves the input parameters and execution status of an entity onboarding workflow. This is done by sending a GET request to the API using the same onboarding ID provided during the PUT request.

```http
GET http://{HOSTNAME}/api/v1/onboardings/onboarding-123
```

--------------------------------

### Observability: Local Grafana Stack Setup with OpenTelemetry Collector

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Instructions to set up a local Grafana observability stack using Docker Compose for monitoring Temporal metrics. This includes starting the stack and accessing Grafana to query metrics from the Temporal SDK.

```bash
# Start local Grafana observability stack
cd observability/grafana

# Option 1: Local Grafana (no cloud account needed)
docker-compose -f docker-compose.otel.yaml --profile local up -d

# Access Grafana at http://localhost:3000 (admin/admin)
# Query metrics: temporal_workflow_*, temporal_activity_*, temporal_worker_*

```

--------------------------------

### Setup Temporal SDK Dashboard in DataDog

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

Automates the upload of the official Temporal SDK dashboard to your DataDog account. This script requires your DataDog API and Application keys to be set in the .env file. It provides the dashboard URL upon successful upload.

```bash
cd datadog
chmod +x setup-dashboard.sh
./setup-dashboard.sh
```

--------------------------------

### Start DataDog Agent for Temporal Metrics

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

This bash script initiates the DataDog Agent for collecting Temporal metrics. It involves navigating to the observability directory, creating a .env file with DataDog credentials, and starting the agent using Docker Compose. The script also provides a command to verify metrics collection.

```bash
# Start DataDog Agent for Temporal metrics collection
cd observability/datadog

# Create .env with credentials
cat > .env << 'EOF'
DD_API_KEY=your_datadog_api_key
DD_SITE=datadoghq.com
DD_TAGS=env:production,team:platform
EOF

# Start the agent
docker compose up -d

# Verify metrics: curl http://localhost:9464/metrics
# View in DataDog: Metrics Explorer > temporal.*

```

--------------------------------

### Start DataDog Agent with Docker Compose

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

Launches the DataDog agent in detached mode using Docker Compose. This command starts the necessary containers for the agent to run and begin collecting metrics. Viewing logs is recommended to confirm successful startup and connection.

```bash
cd datadog
docker compose up -d

# View logs to verify it's running
docker compose logs -f datadog-agent
```

--------------------------------

### Start Entity Onboarding via HTTP PUT

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Starters.md

Initiates an entity onboarding workflow by sending a PUT request to the API. This requires the hostname and a unique onboarding ID. The request body should contain the value for the onboarding process.

```http
PUT http://{HOSTNAME}/api/v1/onboardings/onboarding-123 value=some-value
```

--------------------------------

### Run Temporal .NET Worker

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

Starts the Temporal .NET worker, ensuring it exposes Prometheus metrics on port 9464. This is necessary for the DataDog agent to scrape the metrics. The command assumes the worker's source code is in the specified directory.

```bash
cd src/Onboardings/Onboardings.Workers
dotnet run --configuration=LocalWorker
```

--------------------------------

### Run .NET Worker Services in Cloud via CLI

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Workers.md

Starts the .NET worker services for the Temporal Onboarding project using the 'cloud' launch profile. This command is intended for deployment in a cloud environment and should be run in a separate terminal from the workflow start command.

```shell
dotnet run --launch-profile cloud \
 --project src/Temporal.Curriculum.Workers/Temporal.Curriculum.Workers.Services/Temporal.Curriculum.Workers.Services.csproj
```

--------------------------------

### Verify Temporal Connection and Setup Worker in Spring Boot

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

This Java configuration class demonstrates how to verify the Temporal connection at application startup using Spring Boot's CommandLineRunner. It also sets up a Temporal Worker for processing 'order-processing' workflows and activities.

```java
// Spring Boot: Verify Temporal connection at startup
import io.temporal.client.WorkflowClient;
import io.temporal.worker.Worker;
import io.temporal.worker.WorkerFactory;
import org.springframework.boot.CommandLineRunner;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class TemporalConfig {

    @Bean
    public CommandLineRunner verifyTemporalConnection(WorkflowClient client) {
        return args -> {
            System.out.println("Connected to Temporal namespace: " +
                client.getOptions().getNamespace());
        };
    }

    @Bean
    public WorkerFactory workerFactory(WorkflowClient client) {
        WorkerFactory factory = WorkerFactory.newInstance(client);

        Worker worker = factory.newWorker("order-processing");
        worker.registerWorkflowImplementationTypes(OrderWorkflowImpl.class);
        worker.registerActivitiesImplementations(new OrderActivitiesImpl());

        return factory;
    }
}

// Environment variables for production:
// export TEMPORAL_ADDRESS="your-namespace.tmprl.cloud:7233"
// export TEMPORAL_NAMESPACE="your-namespace"
// export TEMPORAL_API_KEY="tskc_************"
```

--------------------------------

### Start OnboardEntity Workflow in Cloud via CLI

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Workers.md

Initiates an 'OnboardEntity' workflow using the Temporal CLI for a cloud deployment. This command includes environment variable configurations for connecting to the cloud Temporal service, specifying the address, namespace, and TLS certificates.

```shell
export ACCOUNT="sdvdw"
export NAMESPACE="temporal-jumpstart-dotnet.$ACCOUNT"
export ADDRESS="$NAMESPACE.tmprl.cloud:7233"
export TLS_CERT_PATH="localhost-client.pem"
export TLS_KEY_PATH="localhost-client-key.pem"

temporal workflow start \
  --workflow-id onboarding-workers-999 \
  --task-queue onboardings \
  --type OnboardEntity \
  --input '{"Id": "onboarding-workers-999", "Value": "hellocloudworkers"}' \
  --address "$ADDRESS" \
  --namespace "$NAMESPACE" \
  --tls-cert-path $TLS_CERT_PATH \
  --tls-key-path $TLS_KEY_PATH
```

--------------------------------

### Configure DataDog Environment Variables (.env)

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

Sets up the DataDog API key and site URL in a local environment file. This is a crucial step for the DataDog agent to authenticate and connect to your DataDog account. Ensure you replace placeholders with your actual credentials.

```bash
cd datadog
cp .env.sample .env
DD_API_KEY=your_actual_api_key_here
DD_SITE=datadoghq.com  # Change based on your region (see .env.sample for options)
```

--------------------------------

### Run .NET Worker Services Locally via CLI

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Workers.md

Starts the .NET worker services for the Temporal Onboarding project using the 'local' launch profile. This command is typically run in one terminal to initiate the worker process.

```shell
dotnet run --launch-profile local \
 --project src/Temporal.Curriculum.Workers/Temporal.Curriculum.Workers.Services/Temporal.Curriculum.Workers.Services.csproj
```

--------------------------------

### Enable DataDog APM (Traces)

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

Enables Application Performance Monitoring (APM) for your Temporal application by setting the `DD_APM_ENABLED` environment variable. This requires configuring your application to send traces to the specified DataDog agent endpoint.

```bash
# In .env file
DD_APM_ENABLED=true
```

--------------------------------

### Start OnboardEntity Workflow Locally via CLI

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/onboardings/Workers.md

Initiates an 'OnboardEntity' workflow using the Temporal CLI. This command specifies a unique workflow ID, the task queue, and provides input data in JSON format. It's designed for local Temporal deployments.

```shell
temporal workflow start \
  --workflow-id onboarding-workers-999 \
  --task-queue onboardings \
  --type OnboardEntity \
  --input '{"Id": "onboarding-workers-999", "Value": "helloworkers"}' # pay attention to JSON case
```

--------------------------------

### Go SDK: Unit Testing Workflows with Mocked Activities

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Demonstrates how to use `TestWorkflowEnvironment` for unit testing Temporal workflows in Go. It covers mocking activities, executing workflows, and verifying results and state via queries. This approach allows for time-skipping and isolated testing of workflow logic.

```go
// Go SDK: Workflow testing with mocked activities
package workflows_test

import (
    "testing"
    "time"

    "github.com/stretchr/testify/mock"
    "github.com/stretchr/testify/suite"
    "go.temporal.io/sdk/testsuite"
)

type OrderWorkflowTestSuite struct {
    suite.Suite
    testsuite.WorkflowTestSuite
    env *testsuite.TestWorkflowEnvironment
}

func (s *OrderWorkflowTestSuite) SetupTest() {
    s.env = s.NewTestWorkflowEnvironment()
}

func (s *OrderWorkflowTestSuite) AfterTest(suiteName, testName string) {
    s.env.AssertExpectations(s.T())
}

func (s *OrderWorkflowTestSuite) TestOrderWorkflow_Success() {
    // Mock activities
    s.env.OnActivity(activities.ValidateOrder, mock.Anything, mock.Anything).
        Return(&ValidationResult{Valid: true}, nil)

    s.env.OnActivity(activities.ProcessPayment, mock.Anything, mock.Anything).
        Return(&PaymentResult{TransactionID: "tx-123"}, nil)

    s.env.OnActivity(activities.ShipOrder, mock.Anything, mock.Anything).
        Return(&ShipmentResult{TrackingNumber: "TRACK-456"}, nil)

    // Execute workflow
    s.env.ExecuteWorkflow(OrderWorkflow, OrderInput{
        OrderID: "order-001",
        Items:   []Item{{SKU: "ITEM-1", Quantity: 2}},
    })

    s.True(s.env.IsWorkflowCompleted())
    s.NoError(s.env.GetWorkflowError())

    // Verify result via query
    var state OrderState
    val, err := s.env.QueryWorkflow("getState")
    s.NoError(err)
    s.NoError(val.Get(&state))
    s.Equal("completed", state.Status)
    s.Equal("tx-123", state.PaymentID)
}

func (s *OrderWorkflowTestSuite) TestOrderWorkflow_ApprovalTimeout() {
    // Mock activities
    s.env.OnActivity(activities.RequestApproval, mock.Anything, mock.Anything).Return(nil)
    s.env.OnActivity(activities.NotifyTimeout, mock.Anything, mock.Anything).Return(nil)

    // Execute with configurable short timeout for testing
    s.env.ExecuteWorkflow(OrderWorkflow, OrderInput{
        OrderID: "order-002",
        ExecutionOptions: &ExecutionOptions{
            ApprovalTimeoutSeconds: 60, // 1 minute for tests vs 7 days in production
        },
    })

    s.True(s.env.IsWorkflowCompleted())

    var state OrderState
    val, _ := s.env.QueryWorkflow("getState")
    val.Get(&state)
    s.Equal("approval_timeout", state.Status)
}

func TestOrderWorkflowSuite(t *testing.T) {
    suite.Run(t, new(OrderWorkflowTestSuite))
}

```

--------------------------------

### Override Metric Types in YAML

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/observability/datadog/DATADOG_SETUP.md

This YAML configuration allows you to override the default metric types for specific metrics. This is helpful when DataDog misinterprets a metric's type or when you need to enforce a specific type for accurate aggregation and alerting. The example shows overriding types for workflow completion, latency, and worker task slots.

```yaml
type_overrides:
  temporal_workflow_completed: counter
  temporal_workflow_endtoend_latency: histogram
  temporal_worker_task_slots_available: gauge
```

--------------------------------

### Go SDK: Activity with Heartbeating and Idempotency

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Demonstrates how to implement an activity in Go that supports heartbeating for long-running operations and idempotency to handle retries. It uses `activity.RecordHeartbeat` and `activity.GetHeartbeatDetails` for state management. Configure activity options like `StartToCloseTimeout` and `HeartbeatTimeout` in the workflow.

```go
// Go SDK: Activity with heartbeating and idempotency
package activities

import (
    "context"
    "time"

    "go.temporal.io/sdk/activity"
)

type PaymentActivities struct {
    paymentClient PaymentServiceClient
}

// ProcessPayment demonstrates heartbeating for long-running activities
func (a *PaymentActivities) ProcessPayment(ctx context.Context, paymentID string, amount float64) (string, error) {
    logger := activity.GetLogger(ctx)

    // Check for previous attempt details (idempotency via heartbeat)
    if activity.HasHeartbeatDetails(ctx) {
        var previousTxID string
        if err := activity.GetHeartbeatDetails(ctx, &previousTxID); err == nil && previousTxID != "" {
            // Verify previous transaction completed
            status, err := a.paymentClient.GetTransactionStatus(ctx, previousTxID)
            if err == nil && status == "completed" {
                logger.Info("Resuming from previous successful transaction", "txID", previousTxID)
                return previousTxID, nil
            }
        }
    }

    // Create idempotency key from workflow context
    info := activity.GetInfo(ctx)
    idempotencyKey := fmt.Sprintf("%s-%s-%d", info.WorkflowExecution.ID, paymentID, info.Attempt)

    // Submit payment with idempotency key
    txID, err := a.paymentClient.SubmitPayment(ctx, paymentID, amount, idempotencyKey)
    if err != nil {
        return "", err
    }

    // Heartbeat with transaction ID for resume capability
    activity.RecordHeartbeat(ctx, txID)

    // Poll for completion with periodic heartbeats
    for {
        select {
        case <-ctx.Done():
            return "", ctx.Err()
        case <-time.After(5 * time.Second):
            activity.RecordHeartbeat(ctx, txID)

            status, err := a.paymentClient.GetTransactionStatus(ctx, txID)
            if err != nil {
                return "", err
            }
            if status == "completed" {
                return txID, nil
            }
        }
    }
}

// Configure activity options in workflow
// activityOptions := workflow.ActivityOptions{
//     StartToCloseTimeout: 10 * time.Minute,  // Based on user experience SLA
//     HeartbeatTimeout:    30 * time.Second,  // SDK batches at 80% (24 seconds)
//     RetryPolicy: &temporal.RetryPolicy{
//         MaximumInterval: time.Minute,
//     },
// }

```

--------------------------------

### DataDog Queries for Temporal Monitoring

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

This section provides example DataDog queries for monitoring key Temporal performance indicators. It includes queries for schedule-to-start latency, sync match rate, workflow success rate, and available worker task slots. These queries are designed to help identify potential issues and monitor the health of Temporal services.

```datadog_query
# DataDog queries for Temporal monitoring

# Schedule-to-start latency (p99)
p99:temporal_workflow_task_schedule_to_start_latency{namespace:$namespace} by {task_queue}

# Sync match rate
sum:temporal.cloud.v0_poll_success_sync{$Namespace}.as_rate() /
sum:temporal.cloud.v0_poll_success{$Namespace}.as_rate()

# Workflow success rate
(sum:temporal.cloud.v0_workflow_success{$Namespace}.as_rate() /
 (sum:temporal.cloud.v0_workflow_success{$Namespace}.as_rate() +
  sum:temporal.cloud.v0_workflow_failed{$Namespace}.as_rate())) * 100

# Worker task slots available - Alert if = 0
temporal_worker_task_slots_available{namespace:$namespace,worker_type:workflowworker}

```

--------------------------------

### Define Workflow with Signals and Queries - TypeScript

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Illustrates defining a Temporal workflow using the TypeScript SDK, including state management, signal handlers, query handlers, and activity proxying. It demonstrates a configurable approval process with timeouts.

```typescript
import { proxyActivities, defineQuery, defineSignal, setHandler, sleep, condition } from '@temporalio/workflow';

// Configurable input for testability
interface ExecutionOptions {
  approvalTimeoutSeconds?: number;
}

interface OnboardingArgs {
  userId: string;
  executionOptions?: ExecutionOptions;
}

interface WorkflowState {
  userId: string;
  approved: boolean | null;
  completedSteps: string[];
}

// Define queries and signals
export const getStateQuery = defineQuery<WorkflowState>('getState');
export const approveSignal = defineSignal<[boolean]>('approve');

export async function onboardingWorkflow(args: OnboardingArgs): Promise<WorkflowState> {
  // 1. Initialize state
  const state: WorkflowState = {
    userId: args.userId,
    approved: null,
    completedSteps: [],
  };

  // 2. Configure read handlers (queries)
  setHandler(getStateQuery, () => state);

  // 3. Configure write handlers (signals)
  setHandler(approveSignal, (approved: boolean) => {
    state.approved = approved;
  });

  // 4. Load context via activities
  const { sendWelcomeEmail, setupAccount, notifyAdmin } = proxyActivities<Activities>({
    startToCloseTimeout: '30 seconds',
  });

  // 5. Perform behavior
  await sendWelcomeEmail(state.userId);
  state.completedSteps.push('welcome_email');

  // Wait for approval with configurable timeout (defaults to 7 days)
  const timeoutMs = (args.executionOptions?.approvalTimeoutSeconds ?? 604800) * 1000;
  const approved = await condition(() => state.approved !== null, timeoutMs);

  if (state.approved) {
    await setupAccount(state.userId);
    state.completedSteps.push('account_setup');
  } else {
    await notifyAdmin(state.userId, 'approval_timeout');
  }

  return state;
}
```

--------------------------------

### Schedule Workflow with Start Delay

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/foundations/Callers.md

Specifies a duration to wait before dispatching the first Workflow Task. Useful for scheduled Workflows or delayed job processing. Signals sent during the delay are queued. Cannot be combined with `CronSchedule`.

```Go
import (
	"go.temporal.io/sdk/client"
	"time"
)

func main() {
	options := client.StartWorkflowOptions{
		StartDelay: time.Hour * 24, // Example: 24 hours delay
	}
	// ... start workflow with options
}
```

```TypeScript
import {
	WorkflowOptions,
} from '@temporalio/client';

const options: WorkflowOptions = {
	startDelay: 86400000, // Example: 24 hours in milliseconds
};
// ... start workflow with options
```

```Python
from temporalio import workflow
import datetime

options = workflow.WorkflowOptions(
    start_delay=datetime.timedelta(days=1) # Example: 1 day delay
)
# ... start workflow with options
```

```.NET
using Temporalio.Client;

var options = new WorkflowOptions
{
    StartDelay = TimeSpan.FromDays(1) // Example: 1 day delay
};
// ... start workflow with options
```

```PHP
use Temporalio\TemporalioContracts\V1\WorkflowOptions;

$options = new WorkflowOptions([
    'start_delay' => 86400, // Example: 1 day in seconds
]);
// ... start workflow with options
```

--------------------------------

### Handle Workflow ID Conflicts with UseExisting Policy

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/foundations/Callers.md

Demonstrates how to use WorkflowIdConflictPolicy.USE_EXISTING to safely start or connect to an existing workflow, ensuring idempotency and preventing duplicate executions. This is useful for retry mechanisms and process deduplication.

```java
WorkflowOptions options = WorkflowOptions.newBuilder()
    .setWorkflowId("process-order-12345")
    .setWorkflowIdConflictPolicy(WorkflowIdConflictPolicy.USE_EXISTING)
    .setTaskQueue("orders")
    .build();

OrderWorkflow workflow = client.newWorkflowStub(OrderWorkflow.class, options);
WorkflowExecution execution = WorkflowClient.start(workflow::processOrder, orderData);

// Second call (maybe a retry) - gets handle to existing Workflow
// Does NOT start a second Workflow!
OrderWorkflow workflow2 = client.newWorkflowStub(OrderWorkflow.class, options);
WorkflowExecution execution2 = WorkflowClient.start(workflow2::processOrder, orderData);
// execution.getWorkflowId() == execution2.getWorkflowId()
// execution.getRunId() == execution2.getRunId()
// Both refer to the SAME running Workflow
```

--------------------------------

### Go: Query Handlers and Search Attributes for Workflow State

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Demonstrates setting up query handlers and upserting Search Attributes in a Go Temporal workflow. Query handlers allow clients to read workflow state without affecting execution, while Search Attributes enable cross-workflow visibility and filtering.

```go
package workflows

import (
    "go.temporal.io/sdk/workflow"
    "time"
)

type SubscriptionState struct {
    CustomerID    string
    Plan          string
    Status        string
    Balance       float64
    RenewalDate   time.Time
}

func SubscriptionWorkflow(ctx workflow.Context, customerID string) error {
    state := &SubscriptionState{
        CustomerID: customerID,
        Status:     "active",
    }

    // Register query handler - returns consistent state
    err := workflow.SetQueryHandler(ctx, "getState", func() (*SubscriptionState, error) {
        return state, nil
    })
    if err != nil {
        return err
    }

    // Register specific query for balance
    err = workflow.SetQueryHandler(ctx, "getBalance", func() (float64, error) {
        return state.Balance, nil
    })
    if err != nil {
        return err
    }

    // Upsert Search Attributes for cross-workflow visibility
    // Note: Search Attributes are eventually consistent
    searchAttributes := map[string]interface{}{
        "CustomerId":     customerID,
        "SubscriptionStatus": state.Status,
        "Plan":           state.Plan,
    }
    workflow.UpsertSearchAttributes(ctx, searchAttributes)

    // ... workflow logic
    return nil
}

// Query from client:
// response, err := client.QueryWorkflow(ctx, workflowID, "", "getState")
// var state SubscriptionState
// err = response.Get(&state)

// Search via Visibility API:
// workflows, err := client.ListWorkflow(ctx, &workflowservice.ListWorkflowExecutionsRequest{
//     Query: `CustomerId = "cust-123" AND SubscriptionStatus = "active"`,
// })

```

--------------------------------

### DataDog OpenMetrics Configuration for Temporal

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

This YAML configuration file sets up the DataDog Agent's OpenMetrics integration to collect Temporal metrics. It specifies the endpoint, namespace, and metrics to collect, including configurations for handling histogram buckets as distributions for accurate percentile calculations. It also includes type overrides for specific metrics.

```yaml
# conf.d/openmetrics.d/conf.yaml - DataDog OpenMetrics configuration
init_config:

instances:
  - openmetrics_endpoint: http://host.docker.internal:9464/metrics
    namespace: temporal
    metrics:
      - temporal_*

    # Convert histogram buckets to DataDog distributions for percentiles
    histogram_buckets_as_distributions: true

    # Enable distribution metrics for accurate p50/p95/p99
    collect_histogram_buckets: true
    non_cumulative_histogram_buckets: true

    tags:
      - service:temporal-worker
      - env:production

    # Metric type overrides
    type_overrides:
      temporal_workflow_completed: counter
      temporal_workflow_failed: counter
      temporal_activity_execution_latency: histogram
      temporal_worker_task_slots_available: gauge

```

--------------------------------

### Enable Eager Workflow Execution

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/foundations/Callers.md

Requests eager Workflow start optimization, reducing latency when the Worker and Caller are co-located. This is typically enabled by default for best performance and should only be disabled for specific testing or debugging scenarios.

```Go
import (
	"go.temporal.io/sdk/client"
)

func main() {
	// Eager execution is enabled by default.
	// To disable:
	options := client.StartWorkflowOptions{
		DisableEagerExecution: true,
	}
	// ... start workflow with options
}
```

```TypeScript
import {
	WorkflowOptions,
} from '@temporalio/client';

const options: WorkflowOptions = {
	disableEagerExecution: true, // Example: disable eager execution
};
// ... start workflow with options
```

```Python
from temporalio import workflow

options = workflow.WorkflowOptions(
    disable_eager_execution=True # Example: disable eager execution
)
# ... start workflow with options
```

```.NET
using Temporalio.Client;

var options = new WorkflowOptions
{
    DisableEagerExecution = true // Example: disable eager execution
};
// ... start workflow with options
```

```PHP
use Temporalio\TemporalioContracts\V1\WorkflowOptions;

$options = new WorkflowOptions([
    'disable_eager_execution' => true, // Example: disable eager execution
]);
// ... start workflow with options
```

--------------------------------

### Prometheus Queries for Temporal Monitoring

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

A collection of key Prometheus Query Language (PromQL) queries for monitoring Temporal services. These queries cover workflow task latency, sync match rates, workflow success rates, and non-determinism error detection, useful for setting up alerts and dashboards.

```promql
# Key Prometheus queries for Temporal monitoring

# Schedule-to-start latency (p99) - Alert if > 1000ms
histogram_quantile(0.99, sum(rate(temporal_workflow_task_schedule_to_start_latency_seconds_bucket[5m])) by (le, namespace, task_queue))

# Sync match rate - Alert if < 95%
sum by(temporal_namespace) (rate(temporal_cloud_v0_poll_success_sync_count[5m])) /
sum by(temporal_namespace) (rate(temporal_cloud_v0_poll_success_count[5m]))

# Workflow success rate
(rate(temporal_cloud_v0_workflow_success_count[5m]) /
 (rate(temporal_cloud_v0_workflow_success_count[5m]) +
  rate(temporal_cloud_v0_workflow_failed_count[5m]) +
  rate(temporal_cloud_v0_workflow_timeout_count[5m]))) * 100

# Non-determinism error detection - Alert if > 0
increase(temporal_workflow_task_execution_failed_total{error_type="NonDeterminismError"}[5m])

```

--------------------------------

### DataDog Alert Setup for Resource Exhaustion

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/observability/guide.md

Configures a DataDog alert to monitor Temporal Cloud resource exhaustion errors. It aggregates the `temporal.cloud.v0_resource_exhausted_error` metric, groups by `resource_exhausted_cause`, and alerts when the rate exceeds a defined threshold.

```datadog
sum:temporal.cloud.v0_resource_exhausted_error{$Namespace} by {resource_exhausted_cause}.as_rate()
```

--------------------------------

### Workflow Task Latency (Average) Queries

Source: https://github.com/temporalio/temporal-jumpstart/blob/main/docs/observability/guide.md

Calculates the average latency for workflow tasks, from scheduling to start. This metric provides a general view of workflow task processing time. Deviations from expected low values can signal performance issues.

```Prometheus
sum(increase(temporal_workflow_task_schedule_to_start_latency_seconds_sum[5m])) by (namespace, task_queue)/sum(increase(temporal_workflow_task_schedule_to_start_latency_seconds_count[5m])) by (namespace, task_queue)
```

```DataDog
avg:temporal_workflow_task_schedule_to_start_latency.sum{namespace:$namespace} by {namespace,task_queue} / avg:temporal_workflow_task_schedule_to_start_latency.count{namespace:$namespace} by {namespace,task_queue}
```

--------------------------------

### Java Workflow Versioning with GetVersion

Source: https://context7.com/temporalio/temporal-jumpstart/llms.txt

Demonstrates using `Workflow.getVersion` in Java to implement patched versioning for safe workflow code deployments. This allows introducing new logic or modifying existing logic while ensuring backward compatibility during replay. It handles both workflow-level and loop-iteration-level versioning.

```java
import io.temporal.workflow.Workflow;

public class OrderWorkflowImpl implements OrderWorkflow {

    @Override
    public OrderResult processOrder(OrderInput input) {
        OrderState state = new OrderState(input);

        // Version 1: Original implementation
        // Version 2: Added fraud check before payment
        int version = Workflow.getVersion("fraud-check", Workflow.DEFAULT_VERSION, 2);

        if (version >= 2) {
            // New code path: perform fraud check first
            FraudCheckResult fraudResult = activities.checkFraud(input.getCustomerId(), input.getAmount());
            if (fraudResult.isRejected()) {
                state.setStatus("REJECTED_FRAUD");
                return state.toResult();
            }
        }

        // Existing payment processing (runs for all versions)
        PaymentResult payment = activities.processPayment(input.getPaymentDetails());
        state.setPaymentId(payment.getTransactionId());

        // Version handling for loop iterations (unique changeId per iteration)
        for (int i = 0; i < input.getItems().size(); i++) {
            int itemVersion = Workflow.getVersion(
                "item-processing-" + i,  // Unique changeId per iteration
                Workflow.DEFAULT_VERSION,
                1
            );

            if (itemVersion >= 1) {
                // New: parallel item processing
                activities.processItemAsync(input.getItems().get(i));
            } else {
                // Original: sequential processing
                activities.processItem(input.getItems().get(i));
            }
        }

        return state.toResult();
    }
}

// Replay test to validate version compatibility
// @Test
// public void testReplayCompatibility() {
//     WorkflowReplayer.replayWorkflowExecutionFromResource(
//         "workflow-history.json",
//         OrderWorkflowImpl.class
//     );
// }
```