fix(manager): fix initialization order to prevent nil pointer panic

[qiuzhiqian]

Move initAgent() call before initDbusSignalListen() in NewManager() to ensure userAgents is initialized before session signals are connected.

Also add defensive nil checks in handleSessionNew and handleSessionRemoved as a safety measure.

Bug: https://pms.uniontech.com/bug-view-361789.html

[github-actions]

CLA Assistant Lite bot:
提交邮箱中包含我们的合作伙伴，但您似乎并非合作伙伴的成员或对接人，请联系相关对接人将您添加至组织之中，或由其重新发起 Pull Request。
The commit email domain belongs to one of our partners, but it seems you are not yet a member of the current organization, please contact the contact person to add you to the organization or let them submit the Pull Request.

xml seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request}

[deepin-ci-robot]

deepin pr auto review

你好！我是CodeGeeX。我已仔细审查了你提供的Git Diff代码。本次修改主要涉及将 initAgent() 的调用时机从 main.go 延迟到了 NewManager() 内部，并增加了对 userAgents 是否为空的防御性检查。

整体来看，这次修改的逻辑是合理的，解决了对象初始化顺序可能导致的空指针问题，并增加了防御性编程。但仍有几个方面可以进一步优化，以下是详细的审查意见：

1. 语法与逻辑

评价： 逻辑清晰，修改意图明确。

• 初始化顺序调整：将 initAgent() 移至 NewManager() 中，并注释了“先初始化 userAgents”，这保证了在后续的 initDbusSignalListen() 等方法触发回调时，userAgents 已经准备就绪，修复了潜在的竞态条件或空指针问题。
• 防御性检查：在 handleSessionNew 和 handleSessionRemoved 中增加了 m.userAgents == nil 的检查，防止了空指针引发的服务崩溃。

改进建议：

• 日志级别的选择：当 userAgents 为 nil 时，你使用了 logger.Warning。考虑到这会导致会话添加/移除逻辑被直接跳过，这实际上是一个严重的功能异常（会导致该用户的更新代理失效）。建议将日志级别提升为 logger.Error，以便在生产环境中更容易被监控和发现。

2. 代码质量

评价： 代码可读性较好，但防御性检查存在代码重复。

改进建议：

• 消除重复代码：handleSessionNew 和 handleSessionRemoved 两个方法中都包含了相同的 m.userAgents == nil 检查逻辑。为了提高代码的内聚性和可维护性，建议将此检查提取到一个公共方法中，或者考虑在 userAgents 的底层方法中兼容 nil 调用。
• 注释的一致性：initAgent() 后的注释 // 先初始化 userAgents 是好的，但建议统一注释风格，说明为什么要在这里初始化（例如：// 必须在监听 D-Bus 信号前初始化 userAgents，防止回调时出现空指针）。

3. 代码性能

评价： 本次修改对性能没有负面影响。

改进建议：

• 减少不必要的字符串转换：在 handleSessionNew 中，uidStr := strconv.Itoa(int(userInfo.UID)) 每次有新会话时都会执行。如果 addSession 底层只是将 uidStr 作为 Map 的 key，可以考虑是否可以直接使用 int 或 int32 作为 key，从而避免一次内存分配和字符串转换。当然，这需要视 addSession 的接口定义而定，如果改动范围过大，保持现状亦可。

4. 代码安全

评价： 增加了空指针检查，提升了系统的健壮性和安全性。

改进建议：

• 静默失败的隐患：当 userAgents 未初始化时，代码直接 return 了。这是一种“静默失败”模式。对于系统级守护进程，如果核心组件初始化失败，静默忽略可能会导致系统处于不一致的状态。
  • 更安全的做法：如果 initAgent() 是一个必须成功的步骤，建议在 NewManager() 中，如果 initAgent() 失败或未能正确初始化 userAgents，应当向上层返回 error，甚至在 main.go 中直接 panic 或退出，而不是带着残缺的状态继续运行。
  • 如果 initAgent() 允许延迟恢复，那么当前的 return 是合理的，但必须确保有对应的恢复机制。

---

综合改进后的代码示例

基于以上建议，我为你重构了相关代码，主要优化了日志级别、消除了重复的防御性检查，并增强了代码的健壮性：

manager.go 修改部分：

// NewManager 内部
func NewManager(service *dbusutil.Service, updateApi system.System, c *config.Config) (*Manager, error) {
	// ... 其他代码 ...
	go func() {
		m.setPropHardwareId(updateplatform.GetHardwareId(m.config.IncludeDiskInfo, m.config.GetHardwareIdByHelper))
	}()
	
	// 必须在监听 D-Bus 信号前初始化 userAgents，防止回调时出现空指针
	m.initAgent() 
	if m.userAgents == nil {
		// 核心组件初始化失败，记录严重错误。视业务严格程度，这里也可以考虑 return nil, errors.New("userAgents init failed")
		logger.Error("userAgents failed to initialize, session management will be disabled")
	}
	
	m.initDbusSignalListen()
	m.initDSettingsChangedHandle()
	m.syncThirdPartyDconfig()
	// ... 其他代码 ...
}

// 提取公共的检查方法，消除重复代码
func (m *Manager) isUserAgentsReady() bool {
	if m.userAgents == nil {
		// 提升日志级别，这是一个严重的异常状态
		logger.Error("userAgents not initialized, skipping session operation")
		return false
	}
	return true
}

func (m *Manager) handleSessionNew(sessionId string, sessionPath dbus.ObjectPath) {
	// ... 获取 userInfo 逻辑 ...

	uidStr := strconv.Itoa(int(userInfo.UID))

	if !m.isUserAgentsReady() {
		return
	}

	newlyAdded := m.userAgents.addSession(uidStr, session)
	if newlyAdded {
		m.watchSession(uidStr, session)
	}
}

func (m *Manager) handleSessionRemoved(sessionId string, sessionPath dbus.ObjectPath) {
	logger.Debug("session removed", sessionId, sessionPath)
	if !m.isUserAgentsReady() {
		return
	}
	m.userAgents.removeSession(sessionPath)
}

通过以上调整，代码的健壮性、可维护性和错误可见性都得到了提升。如果有其他疑问，欢迎随时提问！

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: qiuzhiqian, zhaohuiw42

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment