What the Data for This Category Looks Like
The core data for code review and merge management comes from Git repositories, CI pipelines, static scanning reports, and defect libraries. Daily produced documents include merge requests, code review comments, commit records, and branch strategy descriptions. Merge requests contain fields such as changed file lists, associated defect IDs, and reviewer statuses. Commit records include commit hashes and change content. The data update frequency is daily or per commit, and it is synchronized in real time with code changes. Core operations for this category typically revolve around change impact assessment, review comment communication, and conflict resolution.
What Constraints These Characteristics Impose on Tool Calling and Plugins
These data characteristics impose clear constraints on tool calling and plugin configuration. First, data sources are scattered across Git, CI, and defect libraries, so plugins must support pulling and associating multi-source data. Second, data is updated in real time with commits, so tool calls must be triggered when merge request status changes or commits are completed. Third, merge requests contain two types of data: manual review comments and automatic scanning results, so plugins must distinguish field formats from different sources. Finally, change impact assessment relies on changed file lists, so tool calls must accurately pull file change content for the corresponding commit.
How to Configure the Settings
The following configurations are based on FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
toolChoice | auto | Fits the multi-source data auto-calling requirements of merge requests |
| HTTP request timeout setting | 300 seconds | Fits the time required to pull large change sets from Git repositories |
| Function call trigger condition | When merge request status changes | Matches the data update frequency characteristic of per commit or daily |
functionCall | Allow calling defect library queries and CI log pulls | Covers the tool calling scope for core data sources |
| Maximum number of returned entries per single call | Top 10 entries | Matches the typical number of review comments associated with a merge request |
| Context window size | 8000–12000 token | Calibrated based on actual testing for long-text processing in code reviews |
Three Common Misconfiguration Issues
- Incorrectly encapsulating file format parameters when making HTTP requests, resulting in 400 Bad Request. The cause is failing to configure the multipart/form-data request header and parameter structure as required by the target tool.
- Inconsistent results when executing sequential tool calls, returning an empty changed file list. The cause is failing to pull Git data in the order of commit submission times, leading to disordered data timelines.
- Not configuring
toolChoiceto auto mode, resulting in tool calls failing to automatically associate defect IDs with merge requests. The cause is failing to match the correct tool calling strategy based on data characteristics.
How to Verify Correct Configuration
- A test merge request is submitted, and whether the tool automatically pulls associated defect library entries and changed file lists is verified.
- A tool call is triggered, and the returned CI logs and Git commit records are checked for matching the content of the current merge request.
- An HTTP request call with file format parameters is tested, and a 200 OK status code is confirmed to be returned.
toolChoiceis adjusted to manual mode, and manual selection of tool types for calling is verified.
The values provided are common starting points and should be evaluated against samples relevant to the actual deployment environment.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.