Fix/ltm: isolate active reply context from long-term memory and session history

[lingyun14beta]

Attempts to fix #7622.When both group_icl_enable and active_reply.enable are enabled in group chat, the bot loses long-term memory in normal @ conversations — any history beyond max_cnt messages is silently ignored. The root cause is that on_req_llm and record_llm_resp_to_ltm do not distinguish between active-reply-triggered requests and regular @ requests, causing active-reply logic to be applied to all LLM requests.

Modifications / 改动点

constants.py (new file)

• Extract the active-reply marker key as a shared constant to avoid magic strings across modules

long_term_memory.py

• Change the branch condition in on_req_llm from cfg["enable_active_reply"] to cfg["enable_active_reply"] and is_active_reply
• Only requests actually triggered by active replies enter the chatroom rewrite branch
• Regular @ requests retain their full req.contexts and long-term session memory

main.py

• Store id(req) in event extra as a marker before yield, so downstream filters can identify whether the current request was triggered by an active reply
• In decorate_llm_req, set _ltm_active_reply_in_progress when the request id matches, so on_llm_response can precisely identify the active reply response without affecting other plugins
• In record_llm_resp_to_ltm, use _ltm_active_reply_in_progress to skip recording only for the exact active reply response; also add group_icl_enable guard to keep session_chats consistent with handle_message
• Set conversation=None for active replies to prevent chatroom context from being persisted into conv.history
• Clear both markers in after_message_sent to avoid leakage if the event object is reused

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

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

The screenshot above shows `/history` output with active reply enabled after the fix — conversation history is preserved correctly with proper User/Assistant turns.

---

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

Fix separation of active-reply-triggered LLM requests from regular conversations to preserve long-term memory and session history in group chats.

Bug Fixes:

• Ensure only active-reply-triggered LLM requests use the chatroom-style rewrite so normal @ conversations retain full context and long-term memory.
• Prevent active-reply responses from being written into persistent session history to avoid polluting subsequent context.

Enhancements:

• Mark active-reply LLM requests via an event extra flag and clear it after sending to avoid leaking state across reused events.
• Extract a shared constant for the active-reply marker key to eliminate magic strings across modules.

Summary by Sourcery

Fix handling of active-reply-triggered LLM requests so they no longer interfere with normal group conversations or long-term memory persistence.

Bug Fixes:

• Ensure only genuinely active-reply-triggered LLM requests use the chatroom-style prompt rewrite, preserving context and long-term memory for regular @ requests.
• Prevent active-reply responses from being recorded into long-term session history or polluting conversation history when group long-term memory is enabled.

Enhancements:

• Introduce shared constants for active-reply tracking keys and use event extras to mark and clear active-reply LLM requests, avoiding state leakage across reused events.

[sourcery-ai]

Hey - I've left some high level feedback:

• Using id(req) in LTM_ACTIVE_REPLY_KEY to correlate the event and request feels a bit fragile (e.g., if the provider wraps or clones req, or if multiple LLM requests are issued for a single event); consider passing an explicit is_active_reply flag with the request or storing a more stable token instead of relying on object identity.
• event.set_extra(LTM_ACTIVE_REPLY_KEY, None) clears the marker by setting it to None, but get_extra(..., None) cannot distinguish between "never set" and "explicitly cleared"; if you ever need that distinction, consider removing the key entirely instead of assigning None.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Using `id(req)` in `LTM_ACTIVE_REPLY_KEY` to correlate the event and request feels a bit fragile (e.g., if the provider wraps or clones `req`, or if multiple LLM requests are issued for a single event); consider passing an explicit `is_active_reply` flag with the request or storing a more stable token instead of relying on object identity.
- `event.set_extra(LTM_ACTIVE_REPLY_KEY, None)` clears the marker by setting it to `None`, but `get_extra(..., None)` cannot distinguish between "never set" and "explicitly cleared"; if you ever need that distinction, consider removing the key entirely instead of assigning `None`.

---

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

[gemini-code-assist]

Code Review

This pull request introduces a mechanism to distinguish and handle 'active replies' within the Long Term Memory (LTM) system. By using a unique key and request ID stored in the event's metadata, the system now ensures that only specific LLM requests trigger chatroom-style prompt rewriting and prevents these responses from polluting the session history. A review comment suggests that the check for active replies in the recording phase might be too broad, potentially affecting other plugins and leading to inconsistent history if certain configuration flags like group_icl_enable are disabled.

[gemini-code-assist]

The check if event.get_extra(LTM_ACTIVE_REPLY_KEY, None) is not None is too broad; it will skip recording for all LLM responses associated with this event if an active reply was triggered, potentially affecting other plugins. Additionally, this block should also verify the group_icl_enable setting. If group_icl_enable is False but active_reply is True, ltm_enabled remains True, causing bot responses to be recorded in session_chats while user messages are skipped (as handle_message is guarded), leading to an inconsistent history.

[lingyun14beta]

主动回答怎么能把上下文也弄没了😭😭😭还有另一个修复的pr也看看嘛#7624

[lingyun14beta]

@sourcery-ai review

[sourcery-ai]

Hey - I've left some high level feedback:

• Using id(req) as the active-reply marker couples correctness to object identity and assumes only a single LLM request per event; if multiple requests or request cloning ever occurs, consider a more robust correlation mechanism (e.g., a UUID stored both in the event extra and the ProviderRequest).
• You’ve extracted LTM_ACTIVE_REPLY_KEY into constants.py but _ltm_active_reply_in_progress remains a magic string; consider centralizing that key as well to keep the marker management consistent and less error-prone.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Using `id(req)` as the active-reply marker couples correctness to object identity and assumes only a single LLM request per event; if multiple requests or request cloning ever occurs, consider a more robust correlation mechanism (e.g., a UUID stored both in the event extra and the `ProviderRequest`).
- You’ve extracted `LTM_ACTIVE_REPLY_KEY` into `constants.py` but `_ltm_active_reply_in_progress` remains a magic string; consider centralizing that key as well to keep the marker management consistent and less error-prone.

---

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

[lingyun14beta]

@sourcery-ai review

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Relying on id(req) stored in event.extra as the active-reply marker could be fragile if multiple LLM requests are issued for the same event or the request object is wrapped/proxied; consider using an explicit request UUID or a per-event sequence counter instead to make the association more robust.
• The new group_icl_enable guard in record_llm_resp_to_ltm assumes cfg['provider_ltm_settings']['group_icl_enable'] is always present; it may be safer to use .get with a default or validate the config structure before indexing to avoid KeyError in partially configured environments.
• The active-reply flags in event.extra are cleared by setting them to None/False; if get_extra distinguishes between missing and falsy values, consider actually removing these keys to avoid ambiguous state and potential mis-detection in future logic.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Relying on `id(req)` stored in `event.extra` as the active-reply marker could be fragile if multiple LLM requests are issued for the same event or the request object is wrapped/proxied; consider using an explicit request UUID or a per-event sequence counter instead to make the association more robust.
- The new `group_icl_enable` guard in `record_llm_resp_to_ltm` assumes `cfg['provider_ltm_settings']['group_icl_enable']` is always present; it may be safer to use `.get` with a default or validate the config structure before indexing to avoid `KeyError` in partially configured environments.
- The active-reply flags in `event.extra` are cleared by setting them to `None`/`False`; if `get_extra` distinguishes between missing and falsy values, consider actually removing these keys to avoid ambiguous state and potential mis-detection in future logic.

## Individual Comments

### Comment 1
<location path="astrbot/builtin_stars/astrbot/main.py" line_range="114-115" />
<code_context>
     ) -> None:
         """在 LLM 响应后记录对话"""
         if self.ltm and self.ltm_enabled(event):
+            # Skip recording if this response is from an active reply request
+            if event.get_extra(LTM_ACTIVE_REPLY_IN_PROGRESS_KEY, False):
+                return
+            # Only record if group_icl_enable is on, to keep session_chats consistent
</code_context>
<issue_to_address>
**issue (bug_risk):** A single boolean flag on the event may skip recording for unrelated LLM responses.

`LTM_ACTIVE_REPLY_IN_PROGRESS_KEY` is set to `True` in `decorate_llm_req` for the active reply and only cleared in `after_message_sent`. If the same `AstrMessageEvent` is reused for multiple `request_llm` calls in one lifecycle (e.g., by other plugins), later responses will still see this flag as `True` and be skipped by `record_llm_resp_to_ltm`, even when they’re not part of the active reply. To avoid dropping unrelated history, it would be safer to tie this to a specific active-reply request ID (as with `LTM_ACTIVE_REPLY_KEY`) or otherwise scope the flag to a particular request/response pair rather than the whole event.
</issue_to_address>

---

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

[lingyun14beta]

@sourcery-ai review

[sourcery-ai]

Hey - I've left some high level feedback:

• The active-reply tracking relies on id(req) matching later in the pipeline; if other middleware wraps or recreates ProviderRequest objects this could silently disable the active-reply branch, so consider using a stable request identifier field on the request or storing a flag directly on the request instead of relying on id.
• The use of LTM_ACTIVE_REPLY_IN_PROGRESS_KEY assumes a single in-flight LLM request per event; if multiple LLM calls can be made within one AstrMessageEvent, these flags could interfere with each other, so it may be safer to track in-progress state per-request rather than per-event.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The active-reply tracking relies on `id(req)` matching later in the pipeline; if other middleware wraps or recreates `ProviderRequest` objects this could silently disable the active-reply branch, so consider using a stable request identifier field on the request or storing a flag directly on the request instead of relying on `id`.
- The use of `LTM_ACTIVE_REPLY_IN_PROGRESS_KEY` assumes a single in-flight LLM request per event; if multiple LLM calls can be made within one `AstrMessageEvent`, these flags could interfere with each other, so it may be safer to track in-progress state per-request rather than per-event.

---

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