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:
- Keep base64 in POST body (rejected: wastes bandwidth, LLM can't see images as data URIs reliably)
- Upload to GridFS via space-files API (rejected: R2 is CDN-accessible, GridFS is not)
- Build new upload service (rejected: R2StorageService and /engine/media/upload already exist)
- 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
apps/vitto-vscode-extension/src/services/agent-session.service.tsAPIs/backend-vitto-api/src/app/engine/vitto.controller.tsAPIs/backend-vitto-api/src/app/engine/vitto-engine.service.ts
🔗 Related
- Decision ID:
dev_1774730694906_7ebits6 - Session: 284
- Workspace: gspace1
Auto-generated by MCP Smart Consolidation