mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 03:13:41 +08:00
f04d57a483
New endpoint POST /api/v1/channels/webchat/sessions/regenerate. Behavior: 1. Auth (API Key + visitorToken + ownsConversation — same chain as the other session mutations). 2. streamTracker.requestStop() — kill any in-flight stream first so its doOnComplete doesn't race the delete/save below. 3. Find last role=user message (seed) and last role=assistant message (target). 4. Delete the last assistant message if present. 5. Reuse chatStream by handing it a synthetic WebChatRequest whose message is the seed user content. chatStream saves a fresh user message (new id, same content) and starts the agent turn. Trade-off: chatStream saves a new user message rather than replaying the existing one in place, so the user-side message count grows by 1 per regenerate. Acceptable — the alternative (refactoring chatStream into reusable chunks) is a 4-hour distraction from the actual feature, and the extra row is harmless (history still reads naturally: user, asst, user, asst, user, asst instead of user, asst, asst). ConversationService gains findLastMessageByRole() and deleteMessageById() helpers; both are scoped exactly to what regenerate needs. WebChatRegenerateTest (@SpringBootTest, 5 cases): - empty thread (no user message) → error event, no DB change - deletes the last assistant reply (count strictly decreases) - bad token → no DB change (auth fails before mutation) - unknown sessionId → returns emitter without throwing - seeds from the LAST user message when multiple exist Tests don't assert on the actual LLM stream content — that's left for PR 5's WebChatStreamE2ETest, which mocks the chat model. Part of epic #355. |
||
|---|---|---|
| .. | ||
| src | ||
| Dockerfile | ||
| pom.xml | ||
| settings.xml | ||