Principle:Langgenius Dify Pipeline Execution Testing
| Knowledge Sources | Dify |
|---|---|
| Domains | RAG, Pipeline, Frontend |
| Last Updated | 2026-02-12 00:00 GMT |
Overview
Description
Pipeline Execution Testing is the principle governing how users validate and debug their RAG pipelines before and after publishing. Dify provides multiple execution modes that allow users to run pipelines against sample data, preview intermediate results, inspect execution logs, and test individual datasource nodes in isolation.
The testing workflow supports three distinct execution scenarios:
- Full Pipeline Run -- Executes the entire published pipeline workflow end-to-end, processing documents through all nodes from datasource ingestion to indexing. Supports both preview mode (returning intermediate outputs for inspection) and production mode (creating actual indexed documents).
- Datasource Node Single Run -- Executes only the datasource node of a draft pipeline in isolation, enabling users to validate that their data source configuration correctly extracts and transforms content before committing to a full pipeline run.
- Execution Log Inspection -- Retrieves the execution history for a specific document within a dataset, showing the datasource configuration, input data, and processing metadata from previous pipeline runs.
All pipeline runs use a blocking response mode, meaning the API call waits for the complete result before returning, simplifying the client-side handling of execution results.
Usage
Pipeline Execution Testing is relevant whenever a user:
- Wants to preview how a pipeline will process a sample document before running it on the full dataset.
- Needs to debug a datasource node by running it independently to verify data extraction.
- Reviews execution logs to understand why a document was processed in a particular way.
- Validates pipeline changes by comparing preview outputs between the current and previous configurations.
- Tests the pipeline with different datasource types (local file, online document, website crawl, online drive) to ensure compatibility.
Testing is typically performed iteratively: configure, test, review results, adjust, and test again until the pipeline produces the desired chunking and indexing output.
Theoretical Basis
Pipeline Execution Testing follows the Shift-Left Testing philosophy, where validation is performed as early as possible in the development lifecycle. By providing preview and single-node execution capabilities, Dify enables users to catch configuration errors before they affect production data.
Key design principles:
- Preview vs. Production Duality -- The
is_previewflag in the run request determines whether the execution produces inspectable intermediate results (PublishedPipelineRunPreviewResponse) or creates actual indexed documents (PublishedPipelineRunResponse). This dual-mode design prevents accidental data pollution during testing. - Node-Level Isolation -- The datasource single-run capability follows the Unit Testing analogy: testing individual components in isolation before testing the integrated system. The
variables-inspectendpoint specifically supports variable inspection, giving visibility into the data flowing between nodes. - Observability Through Logs -- Execution logs provide post-hoc observability, recording the datasource configuration, input data, and node identifiers for each document processing event. This supports Root Cause Analysis when documents are not indexed as expected.
- Blocking Response Mode -- Using
response_mode: 'blocking'simplifies the testing workflow by eliminating the need for polling or streaming, appropriate for the synchronous nature of testing interactions.