Dar 588 plugins

content/influxdb3/core/reference/internals/durability/_index.md

@@ -12,6 +12,5 @@ source: /shared/influxdb3-internals-reference/durability.md
 ---
 
 <!--
-The content for this page is at
-// SOURCE /content/shared/influxdb3-internals-reference/durability/_index.md
-->
+//SOURCE content/shared/influxdb3-internals-reference/durability.md
+-->

content/influxdb3/enterprise/reference/internals/durability/_index.md

@@ -12,6 +12,5 @@ source: /shared/influxdb3-internals-reference/durability.md
 ---
 
 <!--
-The content for this page is at
-// SOURCE /content/shared/influxdb3-internals-reference/durability/_index.md
-->
+//SOURCE content/shared/influxdb3-internals-reference/durability.md
+-->

content/shared/influxdb3-get-started/processing-engine.md

@@ -3,6 +3,7 @@ The {{% product-name %}} processing engine is an embedded Python virtual machine
 Create processing engine [plugins](#plugin) that run when [triggered](#trigger)
 by specific events.
 
+- [Before you begin](#before-you-begin)
 - [Processing engine terminology](#processing-engine-terminology)
   - [Plugin](#plugin)
   - [Trigger](#trigger)
@@ -31,8 +32,8 @@ what data it receives.
 InfluxDB 3 provides the following types of triggers, each with specific
 specifications:
 
-- **Data write** (`table:` or `all_tables`): Sends a batch of written data (for a specific table or all
-  tables) to a plugin when the database flushes data to the Write-Ahead Log (by default, every second).
+- **WAL rows** (`table:` or `all_tables`): Sends a batch of written data (for a specific table or all
+  tables) to a plugin when the database flushes data to the [Write-Ahead Log (WAL)](/influxdb3/version/reference/internals/durability/#write-ahead-log-wal-persistence (by default, every second).
 - **Scheduled** (`every:` or `cron:`): Executes a plugin on a user-configured schedule (using a
   crontab or a duration). This trigger type is useful for data collection and
   deadman monitoring.
@@ -41,6 +42,16 @@ specifications:
   The plugin receives the HTTP request headers and content, and can parse,
   process, and send the data into the database or to third-party services.
 
+## Before you begin
+
+Before you can use the processing engine, you need:
+
+- A running {{% product-name %}} server
+- An admin token for authentication
+- A database to attach triggers to
+
+If you haven't completed these steps, see [Set up {{% product-name %}}](/influxdb3/version/get-started/setup/).
+
 ## Activate the processing engine
 
 To activate the processing engine, include the `--plugin-dir <PLUGIN_DIR>` option
@@ -67,27 +78,25 @@ to the current working directory of the `influxdb3` server.
 ## Create a plugin
 
 To create a plugin, write and store a Python file in your configured `PLUGIN_DIR`.
-The following example is a data write plugin that processes data before it gets
-persisted to the object store.
+The following example shows a WAL rows plugin, which receives data as it's flushed to the Write-Ahead Log. The example shows how to process, query, and write data from within a plugin.
 
 ##### Example Python plugin for data writes 
 
 ```python
-# This is the basic structure for Python plugin code that runs in the
-# InfluxDB 3 Processing engine.
+# Example: A data write plugin for the InfluxDB 3 Processing Engine
 
 # When creating a trigger, you can provide runtime arguments to your plugin,
 # allowing you to write generic code that uses variables such as monitoring
 # thresholds, environment variables, and host names.
 #
-# Use the following exact signature to define a function for the data write
-# trigger.
-# When you create a trigger for a data write plugin, you specify the database
+# This example implements the process_writes signature compatible with a wal_rows
+# trigger specification.
+# Use the exact signature to define the function.
+# When you create a wal_rows trigger, you specify the database
 # and tables that the plugin receives written data from on every WAL flush
 # (default is once per second).
 def process_writes(influxdb3_local, table_batches, args=None):
-    # here you can see logging. for now this won't do anything, but soon 
-    # we'll capture this so you can query it from system tables
+    # Use logging to track plugin execution
     if args and "arg1" in args:
         influxdb3_local.info("arg1: " + args["arg1"])
 
@@ -144,14 +153,14 @@ def process_writes(influxdb3_local, table_batches, args=None):
 
 ## Test a plugin on the server
 
-Use the [`influxdb3 test wal_plugin`](/influxdb3/version/reference/cli/influxdb3/test/wal_plugin/)
-CLI command to test your processing engine plugin safely without
+Use one of the [`influxdb3 test`](/influxdb3/version/reference/cli/influxdb3/test/)
+CLI commands to test your processing engine plugin safely without
 affecting actual data. During a plugin test:
 
 - A query executed by the plugin queries against the server you send the request to.
 - Writes aren't sent to the server but are returned to you.
 
-To test a plugin:
+To test a `process_writes` (WAL) plugin:
 
 1.  Save the [example plugin code](#example-python-plugin-for-data-writes) to a
     plugin file inside of the plugin directory. If you haven't yet written data
@@ -178,7 +187,7 @@ Replace the following:
 - Optional: {{% code-placeholder-key %}}`INPUT_ARGS`{{% /code-placeholder-key %}}: a comma-delimited list of `<KEY>=<VALUE>` arguments for your plugin code--for example, `arg1=hello,arg2=world`
 - {{% code-placeholder-key %}}`DATABASE_NAME`{{% /code-placeholder-key %}}: the name of the database to test against
 - {{% code-placeholder-key %}}`AUTH_TOKEN`{{% /code-placeholder-key %}}: the {{% token-link "admin" %}} for your {{% product-name %}} server
-- {{% code-placeholder-key %}}`PLUGIN_FILENAME`{{% /code-placeholder-key %}}: the name of the plugin file to test
+- {{% code-placeholder-key %}}`PLUGIN_FILENAME`{{% /code-placeholder-key %}}: the name of the plugin file to test. Provide only the filename (for example, `test.py`), not a relative or absolute path.
 
 ### Example: Test a plugin
 <!-- pytest.mark.skip -->
@@ -196,15 +205,19 @@ influxdb3 test wal_plugin \
   test.py
 ```
 
-The command runs the plugin code with the test data, yields the data to the
-plugin code, and then responds with the plugin result.
+The command runs the plugin code, yields the test data to the
+plugin, and then responds with the plugin result.
 You can quickly see how the plugin behaves, what data it would have written to
 the database, and any errors.
 You can then edit your Python code in the plugins directory, and rerun the test.
 The server reloads the file for every request to the `test` API.
 
-For more information, see [`influxdb3 test wal_plugin`](/influxdb3/version/reference/cli/influxdb3/test/wal_plugin/)
-or run `influxdb3 test wal_plugin -h`.
+For more information about testing plugins, see the following:
+
+- [`influxdb3 test wal_plugin`](/influxdb3/version/reference/cli/influxdb3/test/wal_plugin/)
+or run `influxdb3 test wal_plugin -h`
+- [`influxdb3 test schedule_plugin`](/influxdb3/version/reference/cli/influxdb3/test/schedule_plugin/)
+or run `influxdb3 test schedule_plugin -h`
 
 ## Create a trigger
 
@@ -214,16 +227,26 @@ you're ready to create a trigger to run the plugin. Use the
 to create a trigger.
 
 ```bash
-# Create a trigger that runs the plugin
+# Create a trigger that runs the single-file plugin
 influxdb3 create trigger \
   --token apiv3_0xxx0o0XxXxx00Xxxx000xXXxoo0== \
   --database sensors \
-  --plugin test_plugin \
+  --path test_plugin.py \
   --trigger-spec "table:foo" \
   --trigger-arguments "arg1=hello,arg2=world" \
   trigger1
 ```
 
+> [!Note]
+> 
+> #### Plugin paths
+> 
+> - For **single-file plugins**, provide just the `.py` filename to `--path` (for example, `test_plugin.py`).
+> - For **multi-file plugins**, provide the directory name containing `__init__.py`.
+> 
+> When not using `--upload`, the server resolves paths relative to the configured `--plugin-dir`.
+> For details about multi-file plugin structure, see [Create your plugin file](/influxdb3/version/plugins/#create-your-plugin-file).
+
 ## Enable the trigger
 
 After you have created a plugin and trigger, enter the following command to
@@ -249,7 +272,7 @@ For example, to enable the trigger named `trigger1` in the `sensors` database:
 ```bash
 influxdb3 enable trigger \
   --token apiv3_0xxx0o0XxXxx00Xxxx000xXXxoo0== \
-  --database sensors
+  --database sensors \
   trigger1 
 ```
 

content/shared/influxdb3-get-started/setup.md

@@ -242,7 +242,7 @@ services:
       - --cluster-id=cluster0
       - --object-store=file
       - --data-dir=/var/lib/influxdb3/data
-      - --plugin-dir=/var/lib/influxdb3/plugins
+      - --plugin-dir=/var/lib/influxdb3/plugins  # Optional: only needed for processing engine plugins
     environment:
       - INFLUXDB3_ENTERPRISE_LICENSE_EMAIL=EMAIL_ADDRESS
     volumes:
@@ -275,7 +275,7 @@ services:
       - --node-id=node0
       - --object-store=file
       - --data-dir=/var/lib/influxdb3/data
-      - --plugin-dir=/var/lib/influxdb3/plugins
+      - --plugin-dir=/var/lib/influxdb3/plugins  # Optional: only needed for processing engine plugins
     volumes:
       - type: bind
         # Path to store data on your host system

content/shared/influxdb3-plugins/_index.md

@@ -99,7 +99,8 @@ For more information about configuring distributed environments, see the [Distri
 
 ## Add a Processing Engine plugin
 
-A plugin is a Python script that defines a specific function signature for a trigger (_trigger spec_). When the specified event occurs, InfluxDB runs the plugin.
+A plugin is a Python script that defines a function with a trigger-compatible (_trigger spec_) signature.
+When the specified event occurs, InfluxDB runs the plugin.
 
 ### Choose a plugin strategy
 
@@ -146,7 +147,7 @@ Skip downloading plugins by referencing them directly from GitHub using the `gh:
 # Create a trigger using a plugin from GitHub
 influxdb3 create trigger \
   --trigger-spec "every:1m" \
-  --plugin-filename "gh:influxdata/system_metrics/system_metrics.py" \
+  --path "gh:influxdata/system_metrics/system_metrics.py" \
   --database my_database \
   system_metrics
 ```
@@ -178,7 +179,7 @@ Then reference plugins from your custom repository using the `gh:` prefix:
 # Fetches from: https://internal.company.com/influxdb-plugins/myorg/custom_plugin.py
 influxdb3 create trigger \
   --trigger-spec "every:5m" \
-  --plugin-filename "gh:myorg/custom_plugin.py" \
+  --path "gh:myorg/custom_plugin.py" \
   --database my_database \
   custom_trigger
 ```
@@ -493,10 +494,10 @@ Use the `influxdb3 create trigger` command with the appropriate trigger specific
 ```bash
 influxdb3 create trigger \
   --trigger-spec SPECIFICATION \
-  --plugin-filename PLUGIN_FILE \
+  --path PLUGIN_FILE \
   --database DATABASE_NAME \
   TRIGGER_NAME
- ``` 
+```
 
 {{% /code-placeholders %}}
 
@@ -508,9 +509,14 @@ In the example above, replace the following:
 - {{% code-placeholder-key %}}`TRIGGER_NAME`{{% /code-placeholder-key %}}: Name of the new trigger
 
 > [!Note]
-> When specifying a local plugin file, the `--plugin-filename` parameter
-> _is relative to_ the `--plugin-dir` configured for the server.
-> You don't need to provide an absolute path.
+> #### Plugin paths
+> 
+> - For **single-file plugins**, provide just the `.py` filename to `--path` (for example, `test_plugin.py`).
+> - For **multi-file plugins**, provide the directory name containing `__init__.py`.
+> 
+> When not using `--upload`, the server resolves paths relative to the configured `--plugin-dir`.
+> For details about multi-file plugin structure, see [Create your plugin file](#create-your-plugin-file).
+
 
 ### Trigger specification examples
 
@@ -521,14 +527,14 @@ In the example above, replace the following:
 # The plugin file must be in your configured plugin directory
 influxdb3 create trigger \
   --trigger-spec "table:sensor_data" \
-  --plugin-filename "process_sensors.py" \
+  --path "process_sensors.py" \
   --database my_database \
   sensor_processor
 
 # Trigger on writes to all tables
 influxdb3 create trigger \
   --trigger-spec "all_tables" \
-  --plugin-filename "process_all_data.py" \
+  --path "process_all_data.py" \
   --database my_database \
   all_data_processor
 ```
@@ -547,7 +553,7 @@ you can use trigger arguments and your plugin code to filter out unwanted tables
 influxdb3 create trigger \
   --database DATABASE_NAME \
   --token AUTH_TOKEN \
-  --plugin-filename processor.py \
+  --path processor.py \
   --trigger-spec "all_tables" \
   --trigger-arguments "exclude_tables=temp_data,debug_info,system_logs" \
   data_processor
@@ -590,15 +596,15 @@ def on_write(self, database, table_name, batch):
 # Run every 5 minutes
 influxdb3 create trigger \
   --trigger-spec "every:5m" \
-  --plugin-filename "periodic_check.py" \
+  --path "periodic_check.py" \
   --database my_database \
   regular_check
 
 # Run on a cron schedule (8am daily)
 # Supports extended cron format with seconds
 influxdb3 create trigger \
   --trigger-spec "cron:0 0 8 * * *" \
-  --plugin-filename "daily_report.py" \
+  --path "daily_report.py" \
   --database my_database \
   daily_report
 ```
@@ -611,7 +617,7 @@ The plugin receives the scheduled call time.
 # Create an endpoint at /api/v3/engine/webhook
 influxdb3 create trigger \
   --trigger-spec "request:webhook" \
-  --plugin-filename "webhook_handler.py" \
+  --path "webhook_handler.py" \
   --database my_database \
   webhook_processor
 ```
@@ -644,7 +650,7 @@ Use trigger arguments to pass configuration from a trigger to the plugin it runs
 ```bash
 influxdb3 create trigger \
   --trigger-spec "every:1h" \
-  --plugin-filename "threshold_check.py" \
+  --path "threshold_check.py" \
   --trigger-arguments threshold=90,notify_email=admin@example.com \
   --database my_database \
   threshold_monitor
@@ -672,7 +678,7 @@ To allow multiple instances of the same trigger to run simultaneously, configure
 # Allow multiple trigger instances to run simultaneously
 influxdb3 create trigger \
   --trigger-spec "table:metrics" \
-  --plugin-filename "heavy_process.py" \
+  --path "heavy_process.py" \
   --run-asynchronous \
   --database my_database \
   async_processor
@@ -690,15 +696,15 @@ To configure error handling behavior for a trigger, use the `--error-behavior <E
 # Automatically retry on error
 influxdb3 create trigger \
   --trigger-spec "table:important_data" \
-  --plugin-filename "critical_process.py" \
+  --path "critical_process.py" \
   --error-behavior retry \
   --database my_database \
   critical_processor
 
 # Disable the trigger on error
 influxdb3 create trigger \
   --trigger-spec "request:webhook" \
-  --plugin-filename "webhook_handler.py" \
+  --path "webhook_handler.py" \
   --error-behavior disable \
   --database my_database \
   auto_disable_processor
@@ -879,7 +885,7 @@ Each plugin must run on a node that supports its trigger type:
 
 | Plugin type        | Trigger spec             | Runs on                     |
 |--------------------|--------------------------|-----------------------------|
-| Data write         | `table:` or `all_tables` | Ingester nodes              |
+| WAL rows           | `table:` or `all_tables` | Ingester nodes              |
 | Scheduled          | `every:` or `cron:`      | Any node with scheduler     |
 | HTTP request       | `request:`               | Nodes that serve API traffic|
 

package.json

@@ -34,7 +34,7 @@
     "postcss-cli": ">=9.1.0",
     "prettier": "^3.2.5",
     "prettier-plugin-sql": "^0.18.0",
-    "puppeteer": "^23.11.1",
+    "puppeteer": "^24.35.0",
     "remark": "^15.0.1",
     "remark-frontmatter": "^5.0.0",
     "remark-gfm": "^4.0.1",

scripts/puppeteer/inspect-page.js

@@ -67,7 +67,7 @@ async function inspectPage(page) {
     }
   });
   // Wait a bit for errors to accumulate
-  await page.waitForTimeout(1000);
+  await new Promise(resolve => setTimeout(resolve, 1000));
   report.errors = errors;
 
   // 4. Links analysis

scripts/puppeteer/utils/puppeteer-helpers.js

@@ -35,7 +35,7 @@ export async function launchBrowser(options = {}) {
   } = options;
 
   const launchOptions = {
-    headless: headless ? 'new' : false,
+    headless,
     devtools,
     slowMo,
     args: [