Architecture: How should the VSCode extension leverage existing infrastruc...

Documentation for Sessions

🏗️ Architecture: How should the VSCode extension leverage existing infrastruc...

Date: 2026-03-28
Time: 20:44:58 UTC
Session: gspace1-284.6
Agent: backend
Confidence: 93%
Status: ✅ Documented


📋 Decision Context

Question:

How should the VSCode extension leverage existing infrastructure (R2, MongoDB, Redis) for image handling and session persistence?

Task: S284: R2 image upload + conversation history endpoint for VSCode extension


🎯 Decision Made

Chosen:

R2 upload pipeline matching web vitto-chat: extension uploads images to POST /engine/media/upload (returns R2 signed URL), sends URL in attachments array, backend uses existing buildMultimodalContent() for LLM vision blocks. New GET /engine/agent-session/history endpoint exposes MongoDB conversation history for cloud-backed session sync. Both pipelines reuse existing services (R2StorageService, AgentSessionService) with zero new infrastructure.

Options Considered:

  1. Keep base64 in POST body (rejected: wastes bandwidth, LLM can't see images as data URIs reliably)
  2. Upload to GridFS via space-files API (rejected: R2 is CDN-accessible, GridFS is not)
  3. Build new upload service (rejected: R2StorageService and /engine/media/upload already exist)
  4. Reuse existing R2 + media/upload endpoint (chosen: zero new infrastructure, matches vitto-chat pattern exactly)

💭 Reasoning

Root cause of image blindness: extension was inlining images as base64 data URLs in the POST body text. The LLM received megabytes of raw base64 characters, not visual content. The correct pipeline already existed — WhatsApp channel uses R2StorageService.upload(R2_BUCKETS.chatMedia) → signed URL → buildMultimodalContent() → LLM vision blocks. Web vitto-chat uses POST /engine/media/upload → R2 → URL → attachments array. The extension was the only client not using this pipeline. For session history, AgentSessionService.getConversationHistory() already stores all messages in MongoDB per userId — just no GET endpoint existed to retrieve them from the extension. Added VittoEngineService.getAgentSessionService() getter for controller access.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation