@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/cc8bed8d-eb5d-4486-95e1-d846d35acea3.txt

@@ -1,80 +0,0 @@
----
-description: Learn how the Grepr SaaS offering provides high availability to ensure no or minimal downtime for your Grepr pipelines.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# How does Grepr ensure high availability?
-
-This page describes how high availability (HA) is managed for the Grepr software as a service (SaaS) offering. This HA support ensures no or minimal downtime for your Grepr pipelines. This page includes a description of the primary services in the Grepr architecture, how those services are configured to support HA, and how the system responds to failure scenarios for the services.
-
-## The Grepr architecture
-
-The Grepr SaaS offering runs on the AWS public cloud in the `us-east-1` region. In the `us-east-1` region, Grepr runs compute nodes deployed across three availability zones. These compute nodes run services that implement Grepr functionality.
-
-The main services in this architecture are:
-
-- **Stateless services**: These services serve the Grepr REST APIs, and run on multiple compute nodes across three availability zones. The number of replicas of each service is determined by an autoscaler that scales based on load. Initially, each availability zone runs a single replica, ensuring a minimum of three replicas. As load increases, the autoscaler can add capacity by adding replicas in any availability zone where compute node capacity is available.
-- **Data pipelines**: Data pipelines are stateful services that run Apache Flink jobs to process data. Data pipelines run on multiple compute nodes across three availability zones. To optimize network latency and data transfer, Grepr ensures that the compute nodes hosting a pipeline are co-located by allocating the pipeline's services in a single availability zone. The number of replicas for services running a particular data pipeline is determined by an autoscaler that scales based on load.
-
-## Failure Scenarios
-
-The following describes how the Grepr system responds to various failure scenarios.
-
-### Compute node failures
-
-- **Stateless services**: When a compute node running a stateless service fails, in-flight requests running on that compute node fail. Subsequent requests are routed to services running on healthy compute nodes. If compute node capacity is available, the autoscaler provisions compute capacity to replace the lost capacity.
-- **Data pipelines**: When a compute node running a data pipeline fails, the data pipeline automatically stops its associated job, provisions compute capacity to replace the capacity that was lost because of the failure, then restarts the pipeline from the last checkpoint. You might experience a brief, seconds-long period of downtime while the new resources are being provisioned. You might also see duplicate data sent through the pipeline sink for the period of time that the last checkpoint ran to the time that the compute node failed.
-
-### Availability zone failures
-
-**Stateless Services**: When an availability zone fails, in-flight requests running on compute nodes in that availability zone fail. Subsequent requests are routed to healthy services running on compute nodes in healthy availability zones. If compute node capacity is available, the autoscaler provisions compute capacity in the healthy availability zone.
-
-- **Data Pipelines**: When an availability zone fails, data pipeline services are restarted on compute nodes in healthy availability zones. If this occurs, there is a brief, seconds-long downtime while new resources are being provisioned. You might also see duplicate data sent through the pipeline sink for the period of time that the last checkpoint ran to the time that the compute node failed.
-
-### AWS region failure
-
-In the unlikely event that the `us-east-1` region fails, the Grepr team will manually provision resources in a different AWS region and migrate services to that new region. This process is expected to take approximately one hour.
-
-<HiddenFAQ faqs={[
-  {
-    q: "Where does Grepr run?",
-    a: "Grepr SaaS runs on AWS public cloud in the us-east-1 region. In this region, Grepr deploys compute nodes across three availability zones to provide redundancy and high availability. The multi-zone architecture ensures that failures in one zone don't impact overall service availability."
-  },
-  {
-    q: "What are stateless services in the Grepr architecture?",
-    a: "Stateless services in Grepr serve REST APIs and run on multiple compute nodes across three availability zones. The number of replicas is determined by an autoscaler that scales based on load. Initially, each availability zone runs at least one replica, ensuring a minimum of three replicas total."
-  },
-  {
-    q: "What are data pipelines in the Grepr architecture?",
-    a: "Data pipelines are stateful services that run Apache Flink jobs to process data. They run on multiple compute nodes across three availability zones. To optimize network latency and data transfer, Grepr co-locates a pipeline's services in a single availability zone while scaling based on processing load."
-  },
-  {
-    q: "What happens when a compute node running a stateless service fails?",
-    a: "When a compute node with a stateless service fails, in-flight requests on that node fail, but subsequent requests are routed to other healthy compute nodes. If additional compute capacity is available, the autoscaler provisions replacement capacity to restore the original scale."
-  },
-  {
-    q: "What happens when a compute node running a data pipeline fails?",
-    a: "When a compute node with a data pipeline fails, the pipeline automatically stops its job, provisions replacement compute capacity, then restarts from the last checkpoint. You may experience brief seconds-long downtime during resource provisioning and may see duplicate data for the period between the last checkpoint and the failure."
-  },
-  {
-    q: "What happens during an availability zone failure?",
-    a: "When an availability zone fails, stateless services fail over to healthy zones automatically. Data pipelines are restarted on compute nodes in healthy availability zones, causing brief seconds-long downtime while resources are provisioned. You may see duplicate data for the period between the last checkpoint and the failure."
-  },
-  {
-    q: "What is the expected recovery time for an entire AWS region failure?",
-    a: "In the unlikely event of a complete us-east-1 region failure, the Grepr team manually provisions resources in a different AWS region and migrates services. This process is expected to take approximately one hour, during which Grepr services will be unavailable."
-  },
-  {
-    q: "How do pipelines maintain data consistency after failures?",
-    a: "Grepr data pipelines use checkpoints to maintain consistency. When a pipeline restarts after a failure, it resumes processing from the last checkpoint. While this ensures data integrity, you may see duplicate data sent through the pipeline sink for the period between the last checkpoint and the failure."
-  },
-  {
-    q: "How does Grepr ensure minimal downtime for pipelines?",
-    a: "Grepr ensures high availability through multi-zone deployment across three availability zones, automatic replication and failover of stateless services, checkpoint-based recovery for data pipelines, and automated autoscaling to recover failed services. These mechanisms work together to provide minimal downtime for your pipelines."
-  },
-  {
-    q: "Can I configure high availability settings myself?",
-    a: "High availability is built into the Grepr SaaS offering and is automatically managed by the platform. The multi-zone architecture, replication, autoscaling, and failover mechanisms are configured by Grepr for all deployments. For larger deployments or specific requirements, Grepr offers a private cloud deployment model."
-  }
-]} />

package/build/dist/docs-index/ccf2962a-fd6f-4bb1-96ac-7a7ce32e9946.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/ccf2962a-fd6f-4bb1-96ac-7a7ce32e9946.txt

@@ -1,21 +0,0 @@
-# queryRange
-
-**POST** `/v1/metrics/query_range`
-
-**Operation ID**: `queryRange`
-**Summary**: No summary provided.
-## Tags
-- Status Metrics
-## Request Body
-
-**Content-Type**: `application/x-www-form-urlencoded`
-
-**Schema**: object
-
-## Responses
-
-### default
-
-default response
-
-- **Content-Type**: `application/json` / `QueryResult`

package/build/dist/docs-index/cd395973-f392-4ccc-9920-03e53d1f6e03.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/cd395973-f392-4ccc-9920-03e53d1f6e03.txt

@@ -1,8 +0,0 @@
-# Update
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string

package/build/dist/docs-index/ce92e5fa-f3a5-48a6-86d5-8de13e92d76f.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/ce92e5fa-f3a5-48a6-86d5-8de13e92d76f.txt

@@ -1,131 +0,0 @@
----
-description: Learn how to safely test data transformation changes to a running production pipeline with the Grepr live edit feature.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# View pipeline data flows and test changes with live edit
-
-The Grepr live edit feature allows you to:
-
-- Safely test changes to data transformations in a running production pipeline. Using live edit, you can make and test changes to the pipeline's data processing and transformations without impacting the processing of live data and the flow of that data to your observability tools. After you've validated your changes, you can apply those changes to the production pipeline.
-- See a live view of how data flows and is processed by the running production pipeline. You can use this capability to monitor the data flowing through your pipeline in real time, even if you're not making changes to the pipeline.
-
-The live edit feature works by creating a temporary copy of the current pipeline but excludes the sink, preventing duplicate data from being sent to your observability platform. Your changes run in the copy of the pipeline. The state of the data at each step of the copied pipeline can be seen in the live edit view. You can also use this view to compare the results of processing between the original and copy pipelines, allowing you to get fast feedback on your changes.
-
-<Callout type="info">
-  To ensure that the data passing through the pipeline copy doesn't exceed the UI's capacity, the pipeline copy receives a sampling of the pipeline data. To ensure the pipeline copy is receiving the data you need and the output data contains only the fields you need, you can use filter functionality in the live edit UI. See [Create a subset of data for testing using filters](#filter-source-data).
-</Callout>
-
-Any changes you make that are not applied to the production pipeline are visible only in the pipeline copy, and no data is sent to configured sinks or data lakes. When your changes are tested and ready to apply to production, you can apply them to the original pipeline.
-
-## Using live edit with your pipelines
-
-To use live edit:
-
-1. In the Grepr UI, go to the overview page for your pipeline.
-1. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer**.
-
-   ![The Pipeline Log Viewer pane collapsed.](/images/pipelines/pipeline-log-viewer-collapsed.png)
-
-1. To create and start a temporary copy of your pipeline, in the expanded **Pipeline Log Viewer** pane, click the play icon.
-
-   ![The Pipeline Log Viewer pane expanded.](/images/pipelines/pipeline-log-viewer-expanded.png)
-
-1. Grepr creates a temporary copy of your pipeline and runs it using log events sampled from the original pipeline's source data. The **Pipeline Log Viewer** pane updates to show the status of the pipeline copy as it's created and started.
-
-   ![The Pipeline Log Viewer pane showing the status of the copy pipeline.](/images/pipelines/preview-pipeline-startup.png)
-
-1. When the temporary pipeline copy is provisioned and started, the **Pipeline Log Viewer** pane displays the raw logs sampled from the original pipeline's source data. You can use this view to examine logs at different stages of processing, and to test and validate changes to processing.
-
-   ![The Pipeline Log Viewer pane showing raw logs from the copy pipeline.](/images/pipelines/preview-pipeline-running.png)
-
-To examine logs at different stages of processing, use the **Left table link** or **Right table link** menus to select the stage of processing to view.
-
-![The Pipeline Log Viewer pane showing the processing step dropdown.](/images/pipelines/pipeline-log-viewer-processing-steps.png)
-
-To view details of a log event, click the event in the **Pipeline Log Viewer** pane to open the log detail pane. The log detail pane displays the contents of the selected log event at the selected processing steps. The top bar of the log detail pane displays the event type, such as `INFO`, `ERROR`, or `DEBUG`, and the timestamp of the log message.
-To view the state of the event in the selected processing step in the left table, click **LEFT**. To view the state of the event in the selected processing step in the right table, click **RIGHT**.
-Click **DIFF** to view a JSON comparison of the event state in the left and right panels.
-
-
-![The Pipeline Log Viewer log detail pane](/images/pipelines/pipeline-log-viewer-message-detail.png)
-
-## Create a subset of data for testing using filters [#filter-source-data]
-
-Because the pipeline copy is receiving a sampling of the source data to ensure that the UI's capacity is not exceeded, the **Pipeline Log Viewer** supports functionality to filter source data. This filtering functionality ensures you get the correct data required for your testing. You can also use this feature to select specific columns to include in tables created from the filtered data.
-
-To use the filter functionality, click the filter icon next to the stop icon. In the filter dialogue, select your preferred query syntax from the **Query language** menu, and enter your filter query in the **Sampler query** text box. To select the columns you want to see in a table created from the filtered data, add and remove column names in the **Table Columns** input.
-
-![The filter dialogue in the Pipeline Log Viewer.](/images/pipelines/filter-dialogue.png)
-
-## Example: Use live edit to add and test a pipeline filter
-
-<Callout type="info">
-  - This example uses the pipeline created in the [Build your first Grepr pipeline](/tutorials/first-pipeline) tutorial. If you want to follow the example, first complete that tutorial.
-  - Although this example uses Datadog, you can use the live edit feature with any Grepr-supported observability platform. For the complete list of supported observability vendors, see [Supported integrations](/integrations/support-matrix).
-</Callout>
-
-In this example, you use the following steps to test a filter that removes any log messages received by your Grepr pipeline that are assigned the hostname `my-test-host-1`.
-
-1. In the Grepr UI, go to the overview page for your running pipeline.
-1. In the left pane, click **Pre-parsing filter** to open the filter configuration, and click **Add** next to **Filters**.
-1. Make sure **Query language** is set to **Datadog**, and enter the following expression in the **Query** field:
-
-  ```bash copy
-  -host:my-test-host-1
-  ```
-
-   ![The Pre-parsing filter configuration pane with the filter expression entered.](/images/pipelines/pre-parsing-filter-configuration.png)
-
-1. _Do not_ click **Apply Changes**. Before applying the changes to the production pipeline, use the live edit feature to test and validate the filter.
-1. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer** and click the play icon to create and start a temporary copy of your pipeline with the filter added.
-1. In the **Pipeline Log Viewer** left table, click a log message from `my-test-host-1`. The log detail pane opens. Because the filter removes the log messages from the pipeline, only the **LEFT** table view is displayed.
-
-   ![The Pipeline Log Viewer log detail pane showing a message filtered out of the pipeline.](/images/pipelines/pipeline-log-viewer-filtered-message.png)
-
-1. When you complete validation of your change, click **Apply Changes**  to save the new configuration to the production pipeline.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is the Grepr live edit feature?",
-    a: "Live edit is a feature that allows you to safely test changes to data transformations in a running production pipeline without impacting live data. It creates a temporary copy of your pipeline that excludes sinks, preventing duplicate data from being sent to your observability platform while you test changes."
-  },
-  {
-    q: "How do I start using live edit?",
-    a: "To use live edit, go to the overview page for your running pipeline, click the expand icon in the lower right corner to open the Pipeline Log Viewer, and then click the play icon to create and start a temporary copy of your pipeline with sampled data."
-  },
-  {
-    q: "Will live edit changes affect my production pipeline?",
-    a: "No. Changes made in live edit are only visible in the temporary pipeline copy and do not affect production. No data is sent to configured sinks or data lakes until you explicitly apply the changes to the production pipeline."
-  },
-  {
-    q: "What is the Pipeline Log Viewer?",
-    a: "The Pipeline Log Viewer is a pane in the pipeline overview that displays logs sampled from the original pipeline's source data. It allows you to examine logs at different processing stages, see how transformations affect data, and compare results between the original and test pipelines."
-  },
-  {
-    q: "Can I see how data flows through each stage of my pipeline?",
-    a: "Yes. Use the Pipeline Log Viewer to examine logs at different stages of processing. Select the processing step from the Left table link or Right table menu to see data at that point. Click a log event to open the detail pane and view its state at different processing steps."
-  },
-  {
-    q: "Why does live edit use sampled data instead of all pipeline data?",
-    a: "Live edit uses sampled data to ensure the pipeline copy doesn't exceed the UI's capacity. This prevents performance issues while still providing representative data for testing. You can use filter functionality to select specific data needed for your testing."
-  },
-  {
-    q: "How do I filter the data shown in Pipeline Log Viewer?",
-    a: "Click the filter icon next to the stop icon in the Pipeline Log Viewer. In the filter dialog, select your preferred query language syntax and enter your filter query in the Sampler query text box. You can also add or remove column names in the Table Columns input to customize the displayed data."
-  },
-  {
-    q: "What does DIFF view show in the log detail pane?",
-    a: "DIFF view shows a JSON comparison of an event's state between the left and right panels of the Pipeline Log Viewer. This allows you to see exactly what changed when processing logs through different pipeline stages or comparing original versus modified pipelines."
-  },
-  {
-    q: "How do I apply tested changes to my production pipeline?",
-    a: "After you've validated your changes in live edit, click 'Apply Changes' in the pipeline editor to save the new configuration to the production pipeline. Your changes will be applied to the running pipeline."
-  },
-  {
-    q: "Can I use live edit to monitor data without making changes?",
-    a: "Yes. You can use live edit to see a live view of how data flows and is processed by your running production pipeline without making any modifications. This allows you to monitor pipeline behavior and performance in real-time."
-  }
-]} />

package/build/dist/docs-index/ceb429c0-ca8b-46ff-bbfe-48f644fde212.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/ceb429c0-ca8b-46ff-bbfe-48f644fde212.txt

@@ -1,17 +0,0 @@
-# UsersListInfos
-
-**Type**: `object`
-
-## Properties
-
-- name: members (optional)
-  type: `ItemsCollectionReadUser`
-
-- name: start (optional)
-  type: integer
-
-- name: limit (optional)
-  type: integer
-
-- name: total (optional)
-  type: integer

package/build/dist/docs-index/cf3c1b00-4edb-4e49-b79c-92129de1ffd3.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/cf3c1b00-4edb-4e49-b79c-92129de1ffd3.txt

@@ -1,29 +0,0 @@
-# Get a Datadog integration with exceptions
-
-**GET** `/v1/integrations/datadog/{id}/with-exceptions`
-
-**Operation ID**: `getWithExceptions`
-**Summary**: Get a Datadog integration with exceptions
-Get an integration to connect to Datadog with vendor imported exceptions populated.
-
-## Tags
-- Datadog Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Integration retrieved successfully with exceptions
-
-- **Content-Type**: `application/json` / `ReadDatadog`
-### 401
-
-Unauthorized
-
-### 404
-
-Integration not found.

package/build/dist/docs-index/cfe4df63-94e8-4e7d-a8fe-840eb234c126.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/cfe4df63-94e8-4e7d-a8fe-840eb234c126.txt

@@ -1,5 +0,0 @@
-# DataWarehouse
-
-The payload containing integration data.
-
-**Type**: `object`

package/build/dist/docs-index/d02966c7-3e06-425a-a9b8-314b32175b26.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d02966c7-3e06-425a-a9b8-314b32175b26.txt

@@ -1,12 +0,0 @@
-# NotQueryNode
-
-**Type**: `object`
-
-## Properties
-
-- name: expression (required)
-  type: `ParsedQueryNode`
-
-- name: type (required)
-  type: enum: `not-query-node`
-  description: A node that represents a negation in a parsed query.

package/build/dist/docs-index/d02e6299-a690-4228-b812-6f8a26d0905c.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d02e6299-a690-4228-b812-6f8a26d0905c.txt

@@ -1,11 +0,0 @@
-# ChunkedOutputEventRecordReadableData
-
-**Type**: `object`
-
-## Properties
-
-- name: type (optional)
-  type: object
-
-- name: closed (optional)
-  type: boolean

package/build/dist/docs-index/d053820a-50a8-4528-be74-bfc70af32188.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d053820a-50a8-4528-be74-bfc70af32188.txt

@@ -1,11 +0,0 @@
-# Sumo
-
-The payload containing integration data.
-
-**Type**: `object`
-
-## Properties
-
-- name: endpoint (optional)
-  type: string
-  description: SumoLogic HTTP / OTLP endpoint url base

package/build/dist/docs-index/d0dc8bea-d37f-4354-902e-949e62f6986f.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d0dc8bea-d37f-4354-902e-949e62f6986f.txt

@@ -1,29 +0,0 @@
-# ReadOrgConstraints
-
-**Type**: `object`
-
-## Properties
-
-- name: maxPipelines (required)
-  type: integer
-
-- name: maxDatadogIntegrations (required)
-  type: integer
-
-- name: maxSplunkIntegrations (required)
-  type: integer
-
-- name: maxOtlpIntegrations (required)
-  type: integer
-
-- name: maxSumoIntegrations (required)
-  type: integer
-
-- name: maxNewRelicIntegrations (required)
-  type: integer
-
-- name: maxDataWarehouseIntegrations (required)
-  type: integer
-
-- name: maxS3DataWarehouseIntegrations (required)
-  type: integer

package/build/dist/docs-index/d11aa189-dd48-401a-815f-8a98949c5ab4.json

@@ -1 +0,0 @@
-{"docType":"doc"}

package/build/dist/docs-index/d11aa189-dd48-401a-815f-8a98949c5ab4.txt

@@ -1,80 +0,0 @@
----
-description: Automate Grepr data processing with REST APIs for job management, authentication, rule engine control, and job lifecycle tracking.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Automate Grepr processing with the Grepr REST APIs
-
-The Grepr REST APIs provide programmatic access to create and manage data processing jobs, configure authentication, control rule engines, and monitor job lifecycles. These APIs enable you to automate observability pipelines, integrate Grepr into existing workflows, and build custom applications that process log data at scale. All APIs follow REST conventions, return JSON responses, and require HTTPS authentication.
-
-For documentation of the endpoints in the Grepr REST API, see the [OpenAPI 3.0 specification](/apis/api-spec).
-
-## Authenticate to Grepr REST APIs
-
-Learn how to obtain and use access tokens for Grepr API authentication. This page covers the OAuth 2.0 client credentials flow using Auth0, including how to request credentials from Grepr support, obtain access tokens, and include Bearer tokens in API requests. The authentication system uses organization-specific client IDs and secrets to generate time-limited access tokens that provide access to all Grepr APIs.
-
-See [Authenticate to Grepr REST APIs](/apis/authentication).
-
-## Create and manage Grepr jobs
-
-Comprehensive guide for creating and managing Grepr processing jobs through the REST API. This page covers both synchronous and asynchronous job execution modes, batch and streaming processing types, and how to construct job graphs with vertices and edges. Learn how to submit jobs, poll for status updates, handle job versioning, and implement best practices for production deployments.
-
-See [Create and manage jobs with the Grepr REST API](/apis/job-creation-guide).
-
-## Track the lifecycle of Grepr jobs
-
-Detailed documentation of job lifecycle management and state transitions for Grepr processing jobs. This page explains the different states that jobs can enter during creation, updates, and deletion, including pending, running, stopped, and failed states. Learn how to monitor job health, understand state diagrams for different job types, and handle job rollbacks and version management.
-
-See [Track the lifecycle of jobs with the Grepr REST API](/apis/job-states).
-
-## Use conditions and triggers to control log processing
-
-API documentation for configuring and managing Grepr's rule engine to dynamically control log processing based on defined conditions and triggers. This page covers how to create event-based triggers, configure conditional actions, and implement automated responses to log events. Use the rule engine to implement incident response workflows, dynamic log filtering, and context-aware processing rules.
-
-See [Control log processing with the rule engine REST API](/apis/rule-engine).
-
-<HiddenFAQ
-  faqs={[
-    {
-      q: "How do I authenticate to Grepr REST APIs?",
-      a: "Grepr uses OAuth 2.0 client credentials flow with Auth0. You need to request API credentials from Grepr support, then use those credentials to obtain access tokens. Include the Bearer token in the Authorization header of API requests."
-    },
-    {
-      q: "What types of jobs can I create with the Grepr API?",
-      a: "The Grepr API supports creating ASYNCHRONOUS STREAMING jobs (long-running pipelines), ASYNCHRONOUS BATCH jobs (short-lived queries on scoped data), and SYNCHRONOUS BATCH jobs (real-time queries that stream results back to the client)."
-    },
-    {
-      q: "How do I monitor the status of a job I submitted via API?",
-      a: "Use the GET /jobs endpoint to retrieve job details including the state field, which indicates the current lifecycle state of the job (PENDING, RUNNING, STOPPED, FAILED, FINISHED, etc.). Poll this endpoint to track state transitions."
-    },
-    {
-      q: "Can I update a job after it's running?",
-      a: "Yes, you can submit job updates via API. Updates are versioned, so Grepr maintains the old version while deploying the new version. You can also specify rollbackEnabled to automatically rollback to the previous version if the update fails."
-    },
-    {
-      q: "What are the benefits of using asynchronous job execution?",
-      a: "Asynchronous jobs return a 202 Accepted response immediately and allow you to poll for status updates. This is ideal for long-running processes and allows your application to remain responsive while the job executes in the background."
-    },
-    {
-      q: "How do I delete a job via API?",
-      a: "Submit a DELETE request to the jobs endpoint with the job ID. The job will transition through a deletion lifecycle with states like PENDING_DELETE and FINISHED to ensure a clean shutdown."
-    },
-    {
-      q: "What is a job graph and how do I construct one?",
-      a: "A job graph is a JSON structure that defines the data processing pipeline with vertices (operations like source, sink, grok parsing) and edges (connections between operations). Each vertex has a name, type, and configuration specific to that operation type."
-    },
-    {
-      q: "Can I use the rule engine to trigger automated actions?",
-      a: "Yes, the rule engine supports event-based triggers, conditions, and actions. You can configure the engine to automatically execute backfill jobs, modify log tags, or take other actions when specified conditions are met."
-    },
-    {
-      q: "How do I handle job failures detected via API?",
-      a: "Monitor the job state field in API responses. If a job enters the FAILED state, check the job details for error information. You can then resubmit the job with corrected configuration or use the rollback feature if an update caused the failure."
-    },
-    {
-      q: "What API rate limits should I be aware of?",
-      a: "Consult the OpenAPI 3.0 specification at /apis/api-spec for detailed information about rate limits, required headers, and API behavior. Each endpoint has specific constraints documented in the specification."
-    }
-  ]}
-/>

package/build/dist/docs-index/d15277c5-a7f8-4257-81af-5a4642c91493.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d15277c5-a7f8-4257-81af-5a4642c91493.txt

@@ -1,28 +0,0 @@
-# TemplateOperation
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: templateId (required)
-  type: string
-  description: The ID of the template to use for this operation.
-
-- name: templateVersion (optional)
-  type: integer
-  description: The version of the template to use for this operation. If not specified, the latest version will be used on the next pipeline restart. Note that whether templates are forward- or backward-compatible are dependent on the template script, so updating or downgrading versions may result in an error in the job depending on the script.
-
-- name: templateInputs (optional)
-  type: object
-  description: Inputs to the template. Each entry in the map is added to the scope of the template javascript as a variable and can be accessed directly. In addition to the inputs, a 'user' object is also bound providing information about the current user.
-
-- name: draftMode (optional)
-  type: boolean
-  description: Set as a variable in the script scope, this input tells the script to run in 'draft' mode, which should enable additional outputs from various parts of the built pipeline, according to the Template's defined draft outputs.
-
-- name: type (required)
-  type: enum: `template-operation`
-  description: Runs a template script to generate a subgraph running in place of the operation in the parent graph.

package/build/dist/docs-index/d1cad4c3-3af3-409f-a78e-48694b9895cb.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d1cad4c3-3af3-409f-a78e-48694b9895cb.txt

@@ -1,16 +0,0 @@
-# MetricsIcebergTableSink
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: datasetId (required)
-  type: string
-  description: The id of the dataset to write to
-
-- name: type (required)
-  type: enum: `metrics-iceberg-table-sink`
-  description: Writes metrics to an Iceberg table.

package/build/dist/docs-index/d1db7f7e-a6ce-45ce-9190-fc167521e129.json

@@ -1 +0,0 @@
-{"docType":"api"}

package/build/dist/docs-index/d1db7f7e-a6ce-45ce-9190-fc167521e129.txt

@@ -1,29 +0,0 @@
-# Heartbeat a sync job to keep it alive
-
-**POST** `/v1/jobs/sync/heartbeat`
-
-**Operation ID**: `heartbeatSyncJob`
-**Summary**: Heartbeat a sync job to keep it alive
-Sends a heartbeat to a synchronous job to keep it alive. This is needed to keep the connection open and to prevent the server from closing it.
-
-## Tags
-- Jobs
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: string
-
-## Responses
-
-### 202
-
-Heartbeat submitted successfully
-
-### 400
-
-Bad Request
-
-### 401
-
-Unauthorized

package/build/dist/docs-index/d20416bc-46e2-48c4-851f-6d8dee714734.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d20416bc-46e2-48c4-851f-6d8dee714734.txt

@@ -1,27 +0,0 @@
-# TemplateExternalTriggerException
-
-External trigger exception for template inputs with type field
-
-**Type**: `object`
-
-## Properties
-
-- name: id (required)
-  type: string
-  description: Unique identifier for this exception
-
-- name: triggerId (required)
-  type: string
-  description: ID of the trigger to invoke
-
-- name: variables (optional)
-  type: array of string
-  description: Variables to extract from events
-
-- name: backfillDataTime (optional)
-  type: string
-  description: Time period for backfilling data
-
-- name: stopAggregatingDataTime (optional)
-  type: string
-  description: Time period to stop aggregating data

package/build/dist/docs-index/d2e8891a-ec94-488f-8a05-10f58a51eae0.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d2e8891a-ec94-488f-8a05-10f58a51eae0.txt

@@ -1,3 +0,0 @@
-# ScalarData
-
-**Type**: `object`

package/build/dist/docs-index/d30c40a6-ca1a-467d-a987-c91c9cc68985.json

@@ -1 +0,0 @@
-{"docType":"schema"}

package/build/dist/docs-index/d30c40a6-ca1a-467d-a987-c91c9cc68985.txt

@@ -1,15 +0,0 @@
-# JsonFileFormat
-
-JSON file format.
-
-**Type**: `object`
-
-## Properties
-
-- name: recordsPath (optional)
-  type: array of string
-  description: Path to the list of log records.
-
-- name: charset (optional)
-  type: string
-  description: Character set name such as UTF-8, UTF-16, etc.

package/build/dist/docs-index/d3631755-5534-4a96-8139-56cf4d9c5f44.json

@@ -1 +0,0 @@
-{"docType":"api"}