Shared (multi-user) personal conversations 404 on load and never return an AI response #1281

Issue

Once a personal conversation is shared with another user (chat_type = personal_multi_user), the conversation is unusable end to end. Two independent defects are involved:

1. Every page reload or sidebar click on the shared conversation fires a 404 against the personal messages endpoint and raises a Conversation not found danger toast.
2. Every AI request in the shared conversation fails immediately with Stream interrupted: Chat streaming endpoint is unavailable, so the model is never invoked.

Affects all users of the Collaborative Conversations feature.

Steps to Reproduce

1. Start a normal personal conversation and exchange a few messages.
2. Share it with another user (Add participants), converting it to personal_multi_user.
3. Reload /chats, or click the conversation in the sidebar.
   • Observe the 404 and the error toast.
4. Send a message in the shared conversation (for example @Telemetry How many TM packets have arrived since startup?).
   • Observe the stream error instead of a response.

Expected Behavior

• Selecting or reloading a shared conversation loads its messages from the collaboration endpoint with no failed requests and no error toast.
• Sending a message in a shared conversation streams a normal assistant response.

Actual Behavior

Console on load/select:

addChatTypeBadges: chatType="personal_multi_user", groupName="null"
GET /conversation/9f615422-.../messages?ts=... 404 (Not Found)
Error loading messages: Error: Conversation not found
    at chat-messages.js:2140
    at async selectConversation (chat-conversations.js:1688)

Chat transcript on send:

AI
Stream interrupted before any content was received.
⚠ Stream interrupted: Chat streaming endpoint is unavailable
Response may be incomplete. The partial content above has been saved.

Impact

The Collaborative Conversations feature is effectively broken for personal multi-user chats. There is no workaround — a shared conversation cannot be reloaded cleanly and cannot produce an AI response. Group collaborative conversations use the same stream bridge and are affected by the second defect as well.

Notes

Root cause 1 — personal-only endpoint used for collaborative conversations

selectConversation() in application/single_app/static/js/chat/chat-conversations.js calls loadMessages(conversationId) inside the collaborative branch:

if (isCollaborativeConversation && window.chatCollaboration?.activateConversation) {
    await loadMessages(conversationId);          // personal-only endpoint
    scrollConversationViewToBottom();
    await window.chatCollaboration.activateConversation(conversationId, metadata);
}

loadMessages() fetches /conversation/<id>/messages, whose handler (route_frontend_conversations.get_conversation_messages) only reads cosmos_conversations_container. A collaborative conversation lives in cosmos_collaboration_conversations_container under a different id than its hidden source_conversation_id (see ensure_personal_collaboration_for_legacy_conversation), so the read always raises CosmosResourceNotFoundError → 404.

The call is also redundant: activateConversation() → loadConversationMessages() already clears #chatbox and renders the collaboration messages.

Two side effects regress because of the failing call:

• updateComparisonChatUploadCatalog([]) runs from the catch, so chat uploads in shared conversations never populate the Compare/Analyze picker.
• updateConversationTaskDocumentsFromMessages() never runs, so task documents from the previously viewed conversation stay cached against the wrong conversation.

Root cause 2 — Blueprint migration broke the internal stream endpoint lookup

application/single_app/route_backend_collaboration.py:

internal_stream_view = current_app.view_functions.get('chat_stream_api')
if not callable(internal_stream_view):
    yield _serialize_stream_error('Chat streaming endpoint is unavailable', ...)

Commit 094424bc ("Harden route blueprint security policies") moved every route module onto Blueprints. app.py registers chat routes with register_route_blueprint('backend_chats', ...), so /api/chat/stream is now @bp.route(...) and its Flask endpoint key is backend_chats.chat_stream_api, not chat_stream_api. The lookup returns None and the collaborative stream short-circuits before the model is called.

current_app.view_functions is the only remaining blueprint-prefix assumption in the app — every url_for() call is already dotted.

Collateral

functional_tests/test_collaboration_shared_ai_workflow.py is already failing from the same Blueprint migration: it asserts @app.route('/api/collaboration/conversations/<conversation_id>/stream', ...), which is now @bp.route(...).

Suspected files

• application/single_app/route_backend_collaboration.py
• application/single_app/static/js/chat/chat-conversations.js
• application/single_app/static/js/chat/chat-collaboration.js
• application/single_app/static/js/chat/chat-messages.js
• functional_tests/test_collaboration_shared_ai_workflow.py