fix(bluetooth): display notification when file transfer times out

[ComixHe]

Fix the bug where timeout notification was not displayed during Bluetooth file transfer. The issue was introduced by dde-shell commit:
linuxdeepin/dde-shell@c07b130

Changed the notifyID parameter to 0 in notifyReceiveFileTimeout to ensure the timeout notification is properly shown to the user.

Log: display notification when file transfer times out

Summary by Sourcery

Bug Fixes:

• Ensure the Bluetooth file transfer timeout notification is shown by adjusting the notification identifier used on timeout.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Ensures a Bluetooth file transfer timeout notification is shown by forcing the timeout notification call to use a notify ID of 0 instead of reusing the previous notification ID.

Sequence diagram for Bluetooth file transfer timeout notification

sequenceDiagram
    actor User
    participant ObexAgent
    participant NotificationService

    User->>ObexAgent: StartBluetoothFileTransfer(deviceName, filename)
    ObexAgent-->>User: TransferInProgress

    ObexAgent-->>ObexAgent: DetectCancelReasonExpired
    ObexAgent->>NotificationService: notifyReceiveFileTimeout(notify, 0, filename)
    NotificationService-->>User: ShowTimeoutNotification(filename)

Loading

File-Level Changes

Change	Details	Files
Fix Bluetooth file transfer timeout notification not appearing when a transfer expires.	Update the call to notifyReceiveFileTimeout to pass 0 as the notification ID instead of the existing notifyID when the cancel reason is CancelReasonExpired Keep the timeout handling logic intact while only adjusting the parameter that controls how the notification is issued	bluetooth1/obex_agent.go

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[deepin-ci-robot]

deepin pr auto review

这段代码修改将 notifyReceiveFileTimeout 函数调用中的第二个参数从 notifyID 修改为 0。以下是对该修改的详细审查意见：

1. 语法逻辑

• 审查结果：通过。
• 分析：从语法上看，将变量 notifyID 替换为常量 0 是完全合法的 Go 语言语法。只要函数签名接受该类型的参数（例如 int 或 uint），编译就不会报错。

2. 代码质量

• 审查结果：存疑，建议检查上下文。
• 分析：
  • 逻辑意图：这段代码位于 reason == CancelReasonExpired 分支中，意味着接收文件请求超时。将 ID 设为 0 可能是为了表示这是一个无效的通知 ID，或者是为了复用某个特定的通知槽位。
  • 参数一致性：在同一个函数 requestReceive 的其他分支中，notifyReceiveFileTimeout 可能仍然使用 notifyID。如果 notifyID 是一个递增的计数器或文件句柄，那么在这里强制传 0 可能会导致通知系统无法正确关联到之前发出的超时通知，或者关闭了错误的通知窗口。
  • 可读性：直接使用魔术数字 0 会降低代码的可读性。建议定义一个常量，例如 const InvalidNotifyID = 0，以提高代码的可维护性。

3. 代码性能

• 审查结果：无影响。
• 分析：这是一个简单的参数传递修改，不涉及循环、复杂计算或 I/O 操作，因此对性能没有影响。

4. 代码安全

• 审查结果：潜在风险。
• 分析：
  • 逻辑漏洞：如果 notifyReceiveFileTimeout 函数内部逻辑依赖于这个 ID 来取消或更新特定的 UI 通知（例如关闭弹窗），传入 0 可能会导致错误的操作（例如关闭了 ID 为 0 的其他无关通知，或者根本关闭不了预期的通知）。
  • 资源泄漏：如果 notifyID 代表需要释放的资源句柄，将其替换为 0 可能导致原本应该被释放的资源（对应 notifyID）发生泄漏。

改进建议

1. 确认业务逻辑：
   首先需要确认 notifyReceiveFileTimeout 的实现逻辑。如果它的作用是“关闭一个特定的通知窗口”，那么必须传入正确的 notifyID。如果它的作用仅仅是“记录一条超时日志”或“触发一个全局状态”，那么传入 0 或许是可以接受的。

2. 使用具名常量：
   如果确实需要传入 0 来表示“无效 ID”或“全局通知”，请定义常量替代魔术数字：

   const (
       InvalidNotifyID = 0
   )
   // ...
   a.notifyReceiveFileTimeout(notify, InvalidNotifyID, filename)

3. 检查 notifyID 的来源：
   检查 notifyID 在 requestReceive 函数中是如何生成的。如果它是在超时发生之前就已经生成并用于显示“接收请求”弹窗的，那么在超时逻辑中应该继续使用这个 notifyID 来关闭该弹窗，而不是传入 0。

总结：这个修改在语法上没有问题，但在业务逻辑和资源管理上存在潜在风险。建议在合并前，务必确认 notifyReceiveFileTimeout 函数对第二个参数的具体处理逻辑，确保传入 0 不会导致 UI 显示错误或资源管理问题。如果是为了修复 Bug（例如 notifyID 在此时未初始化），请确保注释清楚原因。

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider replacing the hard-coded 0 notify ID with a named constant or helper to document why a zero value is required for the timeout notification to display correctly.
• It may be helpful to add a short comment near this call (or in notifyReceiveFileTimeout’s doc) explaining the behavioral difference when notifyID is 0 versus a non-zero value, so future changes don’t regress this behavior.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider replacing the hard-coded `0` notify ID with a named constant or helper to document why a zero value is required for the timeout notification to display correctly.
- It may be helpful to add a short comment near this call (or in `notifyReceiveFileTimeout`’s doc) explaining the behavioral difference when `notifyID` is 0 versus a non-zero value, so future changes don’t regress this behavior.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 18202781743, ComixHe

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