fix: split long qqofficial messages by 4000-char limit

[wcqqq1214]

Modifications / 改动点

Fixes #9591 — QQ Official replies longer than 4000 chars get truncated by the platform (error code 40054007). The qqofficial adapter previously sent the full text as-is with no length-based splitting, mirroring how the Telegram adapter splits long messages at 4096 chars.

• astrbot/core/platform/sources/qqofficial/qqofficial_message_event.py

  • Add QQ_MAX_LENGTH = 4000 and _split_message(), which splits over-long text at natural boundaries (paragraph → line → sentence → word → hard cut), aligned with the Telegram adapter's _split_message.
  • Add _split_message_chain_by_length(): applied after the existing media-based split, splitting text-only and media-caption chains longer than 4000 chars into multiple ≤4000-char messages. Media components are kept in the first chunk.
  • In _post_send(), when a C2C streaming flush splits into multiple chains, only the last chain carries the stream payload (the rest are sent non-stream), keeping the QQ stream session id continuous so the final state=10 terminates correctly.

• astrbot/core/platform/sources/qqofficial/qqofficial_platform_adapter.py

  • Apply the same length split in _send_by_session_common() so proactive pushes are split too.

• tests/test_qqofficial_message_length_split.py (new)

  • Unit + integration tests: split respects the limit, media-caption splitting, and C2C streaming keeps the stream on the last chunk only.

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

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

Verification steps: ask the bot for a reply longer than 4000 characters via the QQ Official adapter, then confirm the reply arrives as multiple consecutive messages, each within the limit, with no truncation.

Real verification log (local run with temporary instrumentation; a 4425-char reply split into 2 messages, both sent successfully, no 40054007 error):

[22:06:26.804] [Core] [INFO] [qqofficial.qqofficial_message_event]: [QQOfficial][debug] _post_send buffer -> 2 chunk(s): 3950, 475

Temporary instrumentation code used for the verification above (added only to observe the split count; not part of this PR's final diff):

logger.info(
    f"[QQOfficial][debug] _post_send buffer -> {len(message_chains)} chunk(s): "
    + ", ".join(
        str(len("".join(c.text for c in mc.chain if isinstance(c, Plain))))
        for mc in message_chains
    )
)

Screenshot / 截图位置:

In the second image, you can see that the message is split correctly.

Note: ruff check . and ruff format --check . pass, and the targeted test file passes (8 tests).

---

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.
  / 我确保没有引入新依赖库。
• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Enforce QQ Official single-message length limits by splitting long texts and ensure streaming and proactive messages are sent as multiple bounded chunks.

Bug Fixes:

• Prevent QQ Official messages longer than the platform’s 4000-character limit from being truncated by splitting them into multiple messages.

Enhancements:

• Align QQ Official adapter text splitting behavior with Telegram, including preserving media in the first chunk and handling streaming sessions correctly.

Tests:

• Add unit and integration tests covering QQ Official message length splitting, media-caption handling, C2C streaming behavior, and proactive session sends.

[sourcery-ai]

Hey - I've left some high level feedback:

• In _split_message, using remaining = remaining[split_point:].lstrip() can drop leading spaces/newlines between chunks, so the concatenated chunks no longer exactly match the original text for typical prose; consider avoiding .lstrip() or narrowing what you strip to preserve content faithfully.
• The fallback order for _SPLIT_PATTERNS currently relies on dictionary insertion order; if the paragraph → line → sentence → word priority is important long-term, consider switching to an explicit ordered sequence to make the intended split hierarchy clearer and less fragile.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `_split_message`, using `remaining = remaining[split_point:].lstrip()` can drop leading spaces/newlines between chunks, so the concatenated chunks no longer exactly match the original text for typical prose; consider avoiding `.lstrip()` or narrowing what you strip to preserve content faithfully.
- The fallback order for `_SPLIT_PATTERNS` currently relies on dictionary insertion order; if the paragraph → line → sentence → word priority is important long-term, consider switching to an explicit ordered sequence to make the intended split hierarchy clearer and less fragile.

---

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