fix(cron): trigger llm request hooks before resetting main agent

[Foolllll-J]

Align cron-triggered main-agent wake flow with the normal LLM request path.

Closes #8701

Fixes the inconsistency where cron-triggered main-agent requests did not follow the same hook semantics as normal LLM requests. Previously, plugins relying on OnWaitingLLMRequestEvent or OnLLMRequestEvent could work in regular conversations but not in cron-triggered proactive tasks.

This change limits its scope to the cron path only. It does not alter the hook behavior of background-task result callbacks or other internal wake flows.

• trigger OnWaitingLLMRequestEvent before building the main agent
• build the cron main agent with apply_reset=False
• trigger OnLLMRequestEvent before awaiting reset_coro
• preserve hook-based interception by closing reset_coro when stopped
• add a regression test for cron hook timing

Modifications / 改动点

• Updated astrbot/core/cron/manager.py

  • added OnWaitingLLMRequestEvent before the cron main-agent build flow
  • switched cron main-agent construction to apply_reset=False
  • added OnLLMRequestEvent before awaiting reset_coro
  • preserved early interception behavior by closing reset_coro when the hook stops the event

• Updated tests/unit/test_cron_manager.py

  • added a regression test to verify cron-triggered main-agent requests call LLM request hooks before reset
  • verified the cron path aligns with the normal LLM request timing model

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

Verification steps executed locally:

.\.venv\Scripts\python.exe -m pytest tests/unit/test_cron_manager.py -q
.\.venv\Scripts\python.exe -m ruff check astrbot/core/cron/manager.py tests/unit/test_cron_manager.py
.\.venv\Scripts\python.exe -m py_compile astrbot/core/cron/manager.py tests/unit/test_cron_manager.py

Results:

tests/unit/test_cron_manager.py: 33 passed
ruff check: All checks passed!
py_compile: passed

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Align cron-triggered main-agent wake flow with standard LLM request hook behavior for proactive tasks.

Bug Fixes:

• Ensure cron-triggered main-agent requests fire waiting and main LLM request hooks in the same order and timing as normal LLM requests, including proper handling of reset coroutines when hooks intercept execution.

Tests:

• Add a regression test verifying cron-triggered main-agent wakes invoke LLM request hooks before agent reset and mirror the normal request timing model.

[gemini-code-assist]

Code Review

This pull request updates the cron manager's main agent wake flow to trigger OnWaitingLLMRequestEvent and OnLLMRequestEvent hooks, mirroring the standard request-hook timing, and adds corresponding unit tests. The review feedback suggests defensively checking if reset_coro has a close method before calling it to prevent potential AttributeError exceptions if the coroutine type is refactored in the future.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To ensure defensive programming and prevent potential AttributeErrors, it is safer to check if reset_coro has a close method before calling it. If reset_coro is ever refactored to be a Task, Future, or another custom awaitable that does not implement close(), calling close() directly would raise an error.

Suggested change

	if reset_coro:
	reset_coro.close()
	return
	if reset_coro and hasattr(reset_coro, "close"):
	reset_coro.close()
	return

[sourcery-ai]

Hey - I've left some high level feedback:

• The new reset_coro handling in _woke_main_agent will skip awaiting/closing if runner.step_until_done raises; consider wrapping the body in a try/finally to ensure reset_coro is always awaited/closed even on errors to match the intended lifecycle semantics.
• The hook + apply_reset=False flow in _woke_main_agent now closely mirrors the normal LLM request path; consider extracting this into a shared helper so that cron and non-cron flows reuse the same hook ordering and reset logic to prevent future divergence.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `reset_coro` handling in `_woke_main_agent` will skip awaiting/closing if `runner.step_until_done` raises; consider wrapping the body in a `try/finally` to ensure `reset_coro` is always awaited/closed even on errors to match the intended lifecycle semantics.
- The hook + `apply_reset=False` flow in `_woke_main_agent` now closely mirrors the normal LLM request path; consider extracting this into a shared helper so that cron and non-cron flows reuse the same hook ordering and reset logic to prevent future divergence.

---

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.}