What the data for this category looks like
Data for this category primarily comes from frame rate and resource usage logs exported via engine Profiler, load time and stutter duration records collected from real-device testing, exception stacks from crash platforms, as well as performance test reports, device adaptation lists, optimization records, and crash analysis reports during version iterations. Some records also include hardware configuration information of test devices. The data update frequency is daily or per version iteration cycle. Individual records contain fields such as device model, system version, frame rate value, resource load time, and exception trigger scenario. There is no unified fixed format, and it is dynamically adjusted based on test scenarios.
What constraints these characteristics impose on permission and data isolation
Data in this category involves project-level performance confidential information and test environment resources. Different permission boundaries are typically required based on data source and usage scenario. Multi-source dynamic data must be bound to the teamId and tmbId of the corresponding project to prevent cross-project calls to test logs. Frequently updated test records and optimization documents typically require data retention and isolation rules set per version iteration cycle to prevent leakage of sensitive configurations from old versions. Different device adaptation lists are associated with release regions, so access is usually restricted to team members from the corresponding region only, to avoid compliance risks. Performance test data across teams that is not isolated may lead to project confidential information leakage or failure to pass compliance audits.
How to configure the settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Team Permission Binding | Bind teamId and project performance data tags | Align with the project ownership of the data source, prevent cross-project access |
| Member Permission Granularity | Assign permissions based on test roles (performance testing, engine development, operations) | Align with the operational scope of team responsibilities, restrict unnecessary access |
| Unauthenticated Link Limit | Create up to 100 unauthenticated links per team edition application | Adapt to temporary access needs of performance testing scenarios, prevent resource abuse |
| Data Expiration Time | Set to 7 days | Match the daily updated test data retention cycle, reduce sensitive data retention |
| Permission Check Trigger | Validate interface requests based on teamId | Ensure all data calls comply with project isolation rules, align with the permission check logic of FastGPT v4.17.0 |
Three common configuration mistakes
- Phenomenon: Prompt "No permission to operate this conversation record". Cause: The current user's
teamIdis not bound to the permission group of the corresponding performance test project, resulting in inability to access exclusive test logs. - Phenomenon: The number of created unauthenticated links exceeds the preset limit. Cause: The upper limit configuration of unauthenticated links for team edition applications is not adjusted. The default value is 10, which does not adapt to large-scale testing scenario requirements.
- Phenomenon: Cross-team members can view performance reports of other projects. Cause: Data isolation check at the
teamIdlevel is not enabled, resulting in invalid permission boundaries.
How to confirm the configuration is complete
- Log in to the corresponding team backend, check whether the permission group bound to
teamIdincludes the performance data tags of the current project. - Create an unauthenticated link, verify that the number of created links complies with the preset configuration, and no prompt indicating exceeding the limit appears.
- Switch to an unauthorized team account, attempt to access the performance test report of the target project, confirm that it cannot be loaded normally.
- Submit an interface request, check whether the
teamIdparameter is passed along with the request, ensure that the permission check takes effect.
The values provided are common starting points and should be evaluated against the samples associated with the specific deployment.
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.