Reference only; verify against the target FastGPT release and deployment documentation.
What this category of data looks like
Survey and design ledger and report data mainly comes from multiple types of documents including on-site survey logs, professional design drawings, project progress visas, material entry records, and others. Data updates are triggered irregularly as the project progresses, and the volume of data updated in a single batch fluctuates greatly.
The document structure includes two categories: structured fields and long-text attachments. Structured fields include project number, survey point coordinates, number of design changes, material usage, and others, with units including meters, cubic meters, person-times, batches, and others. Long-text attachments include survey technical descriptions, design plan details, and other content.
What constraints these characteristics impose on workflow orchestration
Multiple scattered data sources require the workflow to support cross-module data pulling and field mapping, to avoid errors from manual organization. The large fluctuation in data volume requires batch execution nodes to adapt to dynamic subtask quantities, preventing resource overload. The mixed document structure of structured and unstructured data requires the workflow to handle field aggregation and long-text parsing separately, adapting to different types of content extraction and format conversion requirements.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
Global variable variables | Configured by project ledger field mapping | Adapt to the aggregation and transfer of multi-source structured fields for survey and design |
| Node timeout period | 600–1200 seconds | Adapt to the time consumption of long-text parsing and cross-data source queries |
Batch execution node nodeId | Configured by subtask type grouping | Distinguish between different types of ledger subtasks such as survey, design, and visa |
| Error capture node | Bound to the corresponding nodeId | Accurately locate failed links in model calls or data pulling |
| Context window | 8000–12000 token | Adapt to the processing of long-text content such as survey reports and design plans |
Three common mistakes
- A 429 Request rate increased too quickly error occurs when calling the large language model. The cause is that no request rate limiting node is configured, and the parallel execution count is not adjusted based on the volume of ledger data for survey and design projects.
- After the batch execution node completes, the subtask results generated within the loop cannot be passed outside the loop. The cause is that
variablesare not used correctly to append subtask data, and the global variable merging logic is not configured in the loop end node. - The workflow terminates directly after a preceding node reports an error. The cause is that no error capture branch is added, and the failure callback configuration for the corresponding
nodeIdis not bound.
How to confirm the configuration is correct
- Trigger a test workflow, check whether the execution log includes the execution record of the node corresponding to
nodeId, and confirm that the field mapping of the global variablevariablesmatches the actual ledger data. - Execute a single piece of survey ledger data as a test, check whether the generated report includes all configured structured fields and long-text content.
- Trigger a batch execution task, confirm that after all subtasks are completed, the global variable contains the result data of all subtasks.
- Simulate a model call error scenario, confirm whether the workflow enters the error capture branch and generates corresponding error logs.
The values provided here are common starting points and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-28.