chore: more logs for cooperation - #652
Conversation
Reviewer's GuideThis PR enhances traceability by injecting comprehensive debug and info logs across the cooperation modules, covering network handling, discovery, configuration I/O, sharing and transferring workflows, UI components, and plugin lifecycle events. Class diagram for updated Settings loggingclassDiagram
class SettingsPrivate {
+fromJsonFile(fileName, data)
+fromJson(json, data)
+toJson(data)
+_q_onFileChanged(filePath)
+DLOG/qInfo statements for file and JSON operations
}
class Settings {
+contains(group, key)
+groups()
+keys(group)
+keyList(group)
+value(group, key, defaultValue)
+setValue(group, key, value)
+setValueNoNotify(group, key, value)
+removeGroup(group)
+isRemovable(group, key)
+remove(group, key)
+sync()
+setAutoSync(autoSync)
+onFileChanged(filePath)
+setWatchChanges(watchChanges)
+DLOG/qInfo statements for all major actions
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey @re2zero - I've reviewed your changes - here's some feedback:
- There’s a very high volume of new log statements—consider trimming redundant entries and using appropriate log levels (INFO vs DEBUG) so production logs remain concise and readable.
- A lot of these logs follow repetitive patterns—think about consolidating them into helper functions or macros for consistency and to reduce boilerplate.
- Many logs are inside performance-sensitive code paths (UI events, loops)—you may want to guard them under debug flags or remove non-critical logs to avoid runtime overhead in release builds.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- There’s a very high volume of new log statements—consider trimming redundant entries and using appropriate log levels (INFO vs DEBUG) so production logs remain concise and readable.
- A lot of these logs follow repetitive patterns—think about consolidating them into helper functions or macros for consistency and to reduce boilerplate.
- Many logs are inside performance-sensitive code paths (UI events, loops)—you may want to guard them under debug flags or remove non-critical logs to avoid runtime overhead in release builds.
## Individual Comments
### Comment 1
<location> `src/lib/cooperation/core/net/compatwrapper.cpp:113` </location>
<code_context>
// 非跨端应用无需处理
- if (appInfo.appname != ipc::CooperRegisterName)
+ if (appInfo.appname != ipc::CooperRegisterName) {
+ DLOG << "App is not CooperRegisterName, skipping";
continue;
+ }
</code_context>
<issue_to_address>
Logging every skipped app in peer list may be excessive.
For large peer lists, this could flood the logs. Consider if logging each skipped app is necessary.
</issue_to_address>
<suggested_fix>
<<<<<<< SEARCH
if (appInfo.appname != ipc::CooperRegisterName) {
DLOG << "App is not CooperRegisterName, skipping";
continue;
}
=======
if (appInfo.appname != ipc::CooperRegisterName) {
continue;
}
>>>>>>> REPLACE
</suggested_fix>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
TAG Bot New tag: 1.1.11 |
Add more logs for cooperation. Log: more logs for cooperation.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: lzwind, re2zero The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Add more logs for cooperation.
Log: more logs for cooperation.
Summary by Sourcery
Add extensive debug and informational logging across cooperation modules to enhance traceability of network operations, discovery, GUI interactions, settings management, and compatibility layers.
Enhancements: