You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Conversation drawer shows the previous attack's conversations after switching attacks #3575
The conversation panel keeps a single component instance across attack switches, and its state reset block only clears the loaded conversations when the new attack id is null. Switching from one attack to another therefore leaves the previous attack's conversation list rendered under the new attack's header until the new fetch resolves, with no loading indicator.
During that window a row click hands the old attack's conversation id to the new attack's context, and the star action can promote an old attack's conversation as the new attack's main conversation. The Chat route keeps the panel mounted across attack changes and forces the drawer open whenever related conversations exist, so the stale window is directly reachable by navigating between attacks.
Expected Behavior
Switching attacks should clear the previous attack's conversations, clear the main id and error, and show the loading state until the new attack's conversations resolve, mirroring the mount behavior.
Reproduction Steps
Open an attack with conversations and the conversation drawer open.
Navigate to a second attack.
The drawer immediately shows the first attack's conversations under the second attack's header.
Minimal Reproduction
The render phase reset in ConversationPanel.tsx gates every setter behind if (!attackResultId).
Activity
TrinityBerserker commentedon Oct 27, 2026
Hi! I'd like to work on this issue. I've reviewed the description and have a good idea of where the problem is. I'll submit a PR once I have a fix.
ManoharPaturi commentedon Oct 27, 2026
🐦[T3T]Berserker 🐦 🐍 (@TrinityBerserker) Thanks for your interest in helping with this issue!
Just to clarify, this issue was already assigned to me by Roman Lutz (@romanlutz), and I've submitted PR #3576 with the fix and a regression test.
Since the issue is already being addressed, I'd appreciate it if we could avoid duplicate work. Would you mind closing your PR #3583?
Thanks for your understanding!