fix: continue updateSource when platform token generation fails with PlatformUpdate disabled

[qiuzhiqian]

No description provided.

[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]

[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

[deepin-ci-robot]

deepin pr auto review

这段代码审查意见如下：

1. 逻辑与控制流

问题分析：
这段代码删除了 return nil, nil 这一行。在 else 分支中，即当 genToken 失败时，代码原本会直接返回。删除这行后，代码逻辑发生了显著变化。

• 修改前（旧逻辑）：如果生成 Token 失败（err != nil），记录警告日志后，函数直接返回 nil, nil。这意味着更新源的操作被中止，并且没有向调用者返回错误信息（error 为 nil），调用者可能误以为操作成功或未执行。
• 修改后（新逻辑）：如果生成 Token 失败，记录警告日志后，代码会继续向下执行（跳出 if/else 块，执行后续代码）。

潜在风险：
如果后续代码依赖于 token 变量（虽然 diff 中未展示后续代码，但通常生成 Token 是为了后续请求使用），那么在 Token 生成失败的情况下继续执行，可能会导致：

• 空指针引用：如果后续代码尝试使用空的 token。
• 无效的网络请求：使用空 token 发起请求，导致后续业务逻辑失败。
• 状态不一致：函数可能在部分失败的情况下继续运行，导致难以追踪的 Bug。

改进建议：

• 方案 A（推荐）：如果生成 Token 是更新源的必要前置条件，那么失败时应该返回错误，而不是静默失败或继续执行。建议将 return nil, nil 改为 return nil, err，以便上层调用者能够感知到错误并进行处理。

  } else {
      logger.Warningf("updatePlatform gen token failed: %v", err)
      return nil, err // 明确向上抛出错误
  }

• 方案 B：如果业务逻辑允许在 Token 生成失败时继续执行（例如降级处理），那么删除 return 是合理的。但必须确保后续代码能够安全地处理 token 为空或无效的情况（例如增加判空保护）。

2. 代码质量

• 错误处理：原代码中的 return nil, nil 是一种“吞掉错误”的做法，这通常是不推荐的，因为它掩盖了问题的真相。删除它虽然改变了逻辑，但如果配合后续的判空处理，可能是一种改进。然而，单纯删除而不增加后续保护，会降低代码的健壮性。

3. 代码安全

• 日志泄露：logger.Warningf("updatePlatform gen token failed: %v", err) 中直接输出了 err。请确保 err 中不包含敏感信息（如密钥、私钥细节等），以免造成日志泄露风险。

总结

这个修改改变了函数的控制流，从“遇到错误直接中止”变成了“遇到错误记录日志并继续”。

• 如果这是有意为之（为了实现降级或容错），请务必检查后续代码是否有对空 Token 的防御性编程。
• 如果这是误操作，建议恢复错误返回机制，并最好返回具体的 err 而不是 nil，以保证错误能被正确追踪和处理。