Reset the conversation Documents pane on New chat

[Paul Lizer (paullizer)]

Fixes #1298

Problem

The chat conversation side drawer has two modes, Contents and Documents. Clicking New chat emptied Contents and closed the drawer, but Documents kept showing the documents from the conversation the user had just left — along with a still-visible header documents toggle, a stale count badge, and a drawer that would not close.

Switching between existing conversations worked correctly; only the New chat path was affected.

Root cause

createNewConversation() signals the reset before the new conversation exists, so the event carries a null id:

notifyConversationContextChanged("new", null, { preserveSelections });

The drawer listener forwarded that as "", and refreshConversationDocuments() resolved the id with an unconditional fallback:

const conversationId = String(options.conversationId || getCurrentConversationId()).trim();

At that moment window.currentConversationId still pointed at the previous conversation — it is only reassigned after the /api/create_conversation response. So the reset signal was executed as "refresh the conversation I'm already on": the old metadata was re-fetched and the old documents re-rendered.

Because documentEntries never became empty, updateDrawerTriggers() never reached its !hasContents && !hasDocuments -> closeDrawer(...) branch.

Contents reset correctly only because it is driven by a different mechanism entirely: the MutationObserver on #chatbox reacting to chatbox.innerHTML = "".

Fix

application/single_app/static/js/chat/chat-conversation-contents.js:

• refreshConversationDocuments() accepts allowCurrentConversationFallback (default true).
• The chat:conversation-context-changed listener passes false, so an empty id means reset rather than reload current.

No new reset logic was needed — the existing if (!conversationId) branch already cleared documentEntries, reset the usage-tracking flags, cleared the status line, showed the empty state, and called updateDrawerTriggers(). It was simply unreachable.

Deliberately preserved:

• reason: "select" always supplies an explicit id, so conversation switching is unchanged.
• The chat:conversation-documents-refresh path (streaming, retry, edit, collaboration) and the module's initial load keep the fallback.
• No second context-changed event is dispatched after creation — that would re-trigger the workspace/prompt/toolbar reset listeners and wipe selections the user made right after starting the new chat.

Validation

A jsdom harness exercised the real module against both the pre-fix and post-fix source, reproducing the reported symptom and confirming the fix:

Check after clicking New chat	Before	After
Documents pane empty	FAIL (2 entries)	PASS
Contents pane empty	PASS	PASS
Documents toggle hidden	FAIL	PASS
Documents count badge hidden	FAIL	PASS
Drawer closed	FAIL	PASS
No metadata refetch for the conversation being left	FAIL (1 fetch for the old conversation)	PASS
Selecting another conversation still loads its documents	PASS	PASS

Functional tests:

• functional_tests/test_chat_new_conversation_documents_drawer_reset.py (new) — 7/7 passed
• functional_tests/test_chat_cited_source_tracking.py — passed
• functional_tests/test_chat_new_conversation_action_state_reset.py — passed

Notes

Two pre-existing test failures were observed and verified to fail identically on the unmodified baseline, so they are out of scope here:

• test_conversation_contents_drawer_settings.py — its AST-extracted user_settings route namespace is missing AI_NOTICE_USER_SETTINGS_KEY, which route_backend_users.py now references.
• test_chat_new_conversation_tag_reset.py — its loadTagsForScope source assertion has drifted from chat-documents.js.

Other changes

• config.py: 0.260.003 → 0.260.004
• docs/explanation/fixes/NEW_CHAT_CONVERSATION_DOCUMENTS_DRAWER_RESET_FIX.md (+ fixes index entry)
• v0.260.004 release-notes entry