Debugging
Describes tools and methods for analyzing and resolving problems that occur during pipeline execution. D.Hub records execution history by pipeline, batch, and step, so you can debug the problem by narrowing it down step by step.
Execution history (Traces)
Detailed execution history (trace) is automatically saved each time the pipeline runs.
Execution history structure
The execution history consists of three layers:
| tier | Description |
|---|---|
| Pipeline | Pipeline Entire Execution Unit |
| Batch | Individual running instances of a pipeline (each run creates a new batch) |
| Step | Execution unit for each node in the deployment |
Check execution history
- Select a code node in the workflow editor and open the History tab in the Properties panel.
- When you select a specific batch from the batch list, details for each step of that batch will be displayed.
If you hover your mouse over the execution history bar at the top, you can quickly view the execution number, status, time, and time required. The information available for each batch is as follows:
| Item | Description |
|---|---|
| Batch ID | Identifier of the running instance |
| Status | Execution result (success/failure/running, etc.) |
| Time Required | Time taken for full run |
Batch status
Each batch is in one of the following states:
| status | Description | Follow-up |
|---|---|---|
| running | Currently running | Wait for completion or stop if necessary |
| Success (ready) | All steps completed successfully | Check output dataset |
| failed / error | An error occurred in one or more steps | After analyzing the error, correct and rerun |
| stop | User interrupts execution | Rerun if necessary |
Error analysis
Check log for each step
Here are the steps to analyze a batch that failed to run:
- Select the failing code node to open its properties panel.
- In the History tab, select the batch marked as failed (red).
- Expand the failed step and check the description and stack trace (a record of the location of the error) (copyable).
Execution failed without step records
Not all failures are recorded step by step. Infrastructure issues that prevent the execution itself from starting (e.g. a running pod fails to pop up) will not leave a checkpoint at any step, so you will not find a stacktrace in the History tab. The reason for this run-level failure is displayed in the error notification (toast) and desktop notification that appear immediately after execution. If there are no failed steps in the history and the batch ended in failure, check the reason for this notification first.
Additionally, if the execution status is not read repeatedly (approximately 1 minute), the query automatically stops and displays Pipeline status unknown. Prevents infinite waiting when the state appears to be frozen.
Error message interpretation
The information that can be found in the step details of the history tab is as follows.
| Item | Description |
|---|---|
| Status | Step execution results (failure, etc.) |
| Description (Error Message) | Message explaining the cause of the error |
| Stack Trace | detailed call stack |
| Start/End Time | Step execution time |
Common error types and solutions
| Error Type | Cause | Solution |
|---|---|---|
| ConnectionError | Data source (DB, API) connection failure | Check network status, authentication information, and endpoint address |
| SchemaError | Schema mismatch of input/output data | Check column name and data type mapping |
| SyntaxError | Syntax errors in Python/SQL code | Modify code syntax and rerun |
| RuntimeError | Exception occurred while executing code | Modify logic by analyzing stack traces |
| TimeoutError | execution timeout | Optimizing queries, reducing data size, adjusting timeout values |
| ResourceError | Insufficient CPU/memory resources | Raise resource limits or handle data splitting |
If the error repeats in the Code node, try logging (print or logging) in your code to check the intermediate data status. You can find the cause faster.
Detailed trace for each step
You can check the following information in the execution history of each step.
| Item | Description |
|---|---|
| Status | Step execution result |
| Start/End Time | Step start/end time |
| Description | Run/Error Description Message |
| Stacktrace | Detailed call stack on failure |
The number of records processed and the time taken can be checked from the status display at the top of the canvas node during execution.
Rerun batch
You can fix a failed batch and run it again.
How to rerun
- Analyze the cause of the failure and fix the code or settings.
- Save your changes.
- Click the Run button in the top toolbar to create a new batch.
When you rerun you will have a new batch. The history of previous failed batches remains and can be used to compare and analyze two batches.
Debugging Best Practices
- Log confirmation order: Narrow the scope and analyze in the following order: Pipeline → Batch → Step.
- Stepwise testing: Complex pipelines add nodes one by one, verifying each step.
- Test with small data: Test with a small amount of sample data first before running the entire data.
- Compare previous successful batch: Compare the input data and settings differences between the failed batch and the previously successful batch.