This document applies to FastGPT v4.17.0.
What this category of data looks like
This category of data primarily originates from Git repositories, CI pipelines, static scanning reports, and defect databases. Daily output includes merge requests, code review comments, commit records, and branch strategy descriptions. Code commit actions or daily batch updates trigger data updates. Each entry contains a list of changed files, reviewer identifiers, original review comments, branch association information, and commit timestamps. All fields use text or enumeration types, with no complex nested structures. The data can be directly used for associated matching of conversation logs.
What constraints these characteristics impose on conversation logs and auditing workflows
This category of data spans multiple tool chains. Conversation logs must associate cross-source identifiers such as merge request IDs and commit record hashes to enable full tracing of change context during audits. Code commit actions trigger frequent data updates, so conversation logs must support incremental pulling to avoid duplicate storage and query overload. Each entry has a relatively fixed field structure, so auditing rules can match compliance requirements using fixed fields, but must accommodate field naming differences across Git platforms. R&D auditing workflows must retain the full communication chain of review comments, avoid missing key manual judgment nodes, and ensure full traceability of code changes.
How to configure settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chatId | Merge request ID | Associate conversations with specific code change contexts, ensuring audits can trace corresponding merge requests |
responseChatItemId | Unique identifier for a single review comment | Precisely locate individual communication content, avoid log confusion between multiple review comments |
detail | Include full changed files and review comments | Cover complete materials required for compliance reviews, meet content requirements for security audits |
| Log storage period | 90 days | Align with standard R&D team audit cycle requirements, balance storage costs and traceability needs |
| Incremental pull interval | 5 minutes | Adapt to the high-frequency update rhythm of code commits, avoid excessive delay impacting real-time audits |
| Log storage path | Read-write local directory or object storage bucket | Ensure log files can be properly written and read, avoid storage failures |
Three common misconfigurations
- Phenomenon: The conversation log details page displays content that does not match actual review communication content, and details remain duplicated after multiple conversation initiations. Cause:
chatIdis not correctly bound to the merge request ID, causing logs from different merge requests to associate with the same session. - Phenomenon: When calling the log query interface to pull full records, the number of returned results is far fewer than the actual number of sessions. Cause: The full synchronization switch is not enabled, only recent session fragments are pulled, and all historical review records are not covered.
- Phenomenon: Running logs cannot be saved to the specified file, triggering a permission denied error. Cause: Read-write permissions for the log storage path are not configured, or the storage quota setting is lower than the total capacity of generated logs.
How to confirm configuration is correct
- Manually initiate a conversation associated with a specific merge request, check if the log contains the correct
chatIdand merge request ID. - Call the log query interface, pass the corresponding
chatId, confirm that the returneddetailfield contains complete review comments and changed file lists. - View the log storage directory, confirm that newly generated log files include that day’s code review conversation records, with no missing or duplicated entries.
- Simulate multiple code commit and review actions, check if logs are incrementally updated at the set 5-minute interval, with no abnormal delays or loss.
The values provided are common starting points and should be measured against local deployment 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-10-19.