From 33cb363651869832a07b1fa00b61fda1ea04237f Mon Sep 17 00:00:00 2001 From: dave Date: Thu, 26 Mar 2026 20:18:00 +0000 Subject: [PATCH] storkit: done 400_bug_whatsapp_and_slack_missing_reset_command_handler --- ..._bot_startup_announcement_after_restart.md | 21 --------- ...and_slack_missing_reset_command_handler.md | 45 +++++++++++++++++++ 2 files changed, 45 insertions(+), 21 deletions(-) delete mode 100644 .storkit/work/1_backlog/396_story_whatsapp_bot_startup_announcement_after_restart.md create mode 100644 .storkit/work/5_done/400_bug_whatsapp_and_slack_missing_reset_command_handler.md diff --git a/.storkit/work/1_backlog/396_story_whatsapp_bot_startup_announcement_after_restart.md b/.storkit/work/1_backlog/396_story_whatsapp_bot_startup_announcement_after_restart.md deleted file mode 100644 index 9f6ccf53..00000000 --- a/.storkit/work/1_backlog/396_story_whatsapp_bot_startup_announcement_after_restart.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -name: "WhatsApp bot startup announcement after restart" ---- - -# Story 396: WhatsApp bot startup announcement after restart - -## User Story - -As a WhatsApp user, I want the bot to announce its presence when it starts up or restarts, like it does in Matrix, so I know it's back online and ready. - -## Acceptance Criteria - -- [ ] Bot sends a startup message to all known WhatsApp senders (from conversation history or ambient rooms) when the server starts -- [ ] Startup message includes the bot name and indicates it is online/ready -- [ ] Slack transport gets the same startup announcement treatment -- [ ] Matrix startup announcement behavior is unaffected -- [ ] After a rebuild command, the new process sends the announcement on startup - -## Out of Scope - -- TBD diff --git a/.storkit/work/5_done/400_bug_whatsapp_and_slack_missing_reset_command_handler.md b/.storkit/work/5_done/400_bug_whatsapp_and_slack_missing_reset_command_handler.md new file mode 100644 index 00000000..0fc8931c --- /dev/null +++ b/.storkit/work/5_done/400_bug_whatsapp_and_slack_missing_reset_command_handler.md @@ -0,0 +1,45 @@ +--- +name: "WhatsApp and Slack missing reset command handler" +--- + +# Bug 400: WhatsApp and Slack missing reset command handler + +## Description + +The reset command has a fallback handler in chat/commands/mod.rs that returns None with a comment saying it's handled before try_handle_command. This is only true for Matrix. WhatsApp and Slack don't have pre-dispatch handling, so None causes fallthrough to LLM. This caused a real outage when stale session IDs couldn't be cleared via the bot after switching from Docker to bare-metal. + +## Implementation Note + +Follow the **rebuild pattern** established in story 402, with one complication: `handle_reset` in `server/src/chat/transport/matrix/reset.rs` takes a Matrix-specific `ConversationHistory` (`Arc>>`), so it cannot be called directly from WhatsApp or Slack. + +**WhatsApp session storage** (`server/src/chat/transport/whatsapp.rs`): +- Type: `WhatsAppConversationHistory = Arc>>` (key = sender phone number) +- Persisted to `.storkit/whatsapp_history.json` via `save_whatsapp_history` + +**Slack session storage** (`server/src/chat/transport/slack.rs`): +- Type: `SlackConversationHistory = Arc>>` (key = channel ID) +- Persisted to `.storkit/slack_history.json` via `save_slack_history` + +**Approach:** +- Use `extract_reset_command` from `server/src/chat/transport/matrix/reset.rs` to detect the command (it works transport-agnostically) +- Implement the reset inline in each transport's async message handler: clear `session_id` and `entries` for the sender/channel key, call the transport's own `save_*_history`, reply with confirmation +- Add async intercepts in `whatsapp.rs` (~line 1107, after the rebuild intercept) and `slack.rs` (~line 845, after the rebuild intercept) +- The fallback handler in `chat/commands/mod.rs` (`handle_reset_fallback`) stays as-is + +## How to Reproduce + +1. Configure bot with transport = "whatsapp" or "slack"\n2. Send "reset" to the bot\n3. Check server logs + +## Actual Result + +Log shows "No command matched, forwarding to LLM" — reset is sent to the LLM as a conversational message instead of clearing the session. + +## Expected Result + +The bot clears the sender's session_id from conversation history and replies with confirmation like "Session cleared." + +## Acceptance Criteria + +- [ ] WhatsApp transport handles reset command: clears sender session_id and replies with confirmation +- [ ] Slack transport handles reset command: clears channel session_id and replies with confirmation +- [ ] Fallback handler in chat/commands/mod.rs no longer silently swallows the reset command