Fix workspace upsert to use workspaceId unique constraint

Co-authored-by: tikazyq <[email protected]>

Author: Copilot

packages/ai/src/__tests__/parsers/copilot.test.ts

@@ -7,7 +7,14 @@
  * Supports four-level hierarchy: Application → Workspace → Session → Turn → Message
  */
 
-import type { ChatSession, ChatTurn, ChatMessage, Application, Workspace, ParserType } from '../types/index.js';
+import type {
+  ChatSession,
+  ChatTurn,
+  ChatMessage,
+  Application,
+  Workspace,
+  ParserType,
+} from '../types/index.js';
 
 /**
  * Abstract base class for AI assistant parsers

packages/ai/src/parsers/base.ts

@@ -67,7 +67,11 @@ export class CopilotParser extends BaseParser {
 
     if (applications.length > 0) {
       const totalWorkspaces = applications.reduce((sum, app) => sum + (app.workspaceCount || 0), 0);
-      console.log(chalk.green(`✓ Found ${applications.length} VS Code installation(s) with ${totalWorkspaces} total workspaces`));
+      console.log(
+        chalk.green(
+          `✓ Found ${applications.length} VS Code installation(s) with ${totalWorkspaces} total workspaces`,
+        ),
+      );
     }
 
     return applications;
@@ -227,7 +231,10 @@ export class CopilotParser extends BaseParser {
 
       return session;
     } catch (error) {
-      console.error(chalk.red(`Error parsing chat session ${sessionId}:`), error instanceof Error ? error.message : String(error));
+      console.error(
+        chalk.red(`Error parsing chat session ${sessionId}:`),
+        error instanceof Error ? error.message : String(error),
+      );
       return null;
     }
   }

packages/ai/src/parsers/copilot.ts

@@ -3,7 +3,7 @@
  * Hierarchy: Application → Workspace → Chat Session → Chat Turn → Chat Message
  */
 
-import type { ChatTurn } from "./chat-turn.js";
+import type { ChatTurn } from './chat-turn.js';
 
 // Session-level metadata based on actual Copilot data structure
 export interface ChatSessionMetadata {

packages/ai/src/types/chat-session.ts

@@ -1,13 +1,13 @@
 /**
  * ChatTurn model for grouping related messages in AI Chat processing
  * Hierarchy: Application → Workspace → Chat Session → Chat Turn → Chat Message
- * 
+ *
  * A ChatTurn represents one complete request-response cycle:
  * - User makes a request (user message)
  * - Assistant responds with multiple actions (assistant messages)
  */
 
-import type { ChatMessage } from "./chat-message.js";
+import type { ChatMessage } from './chat-message.js';
 
 // Turn-level metadata based on actual Copilot data structure
 export interface ChatTurnMetadata {

packages/ai/src/types/chat-turn.ts

@@ -9,18 +9,9 @@
     "incremental": false,
     "baseUrl": ".",
     "paths": {
-      "@/*": [
-        "./src/*"
-      ]
+      "@/*": ["./src/*"]
     }
   },
-  "include": [
-    "src/**/*"
-  ],
-  "exclude": [
-    "node_modules",
-    "build",
-    "**/*.test.ts",
-    "**/*.spec.ts"
-  ]
+  "include": ["src/**/*"],
+  "exclude": ["node_modules", "build", "**/*.test.ts", "**/*.spec.ts"]
 }

packages/ai/tsconfig.json

@@ -66,11 +66,13 @@ devlog-collector status
 ### Real-Time Monitoring Only
 
 The collector currently operates in **real-time mode only**. When started:
+
 - ✅ Discovers agent log file locations automatically
 - ✅ Watches files for future changes (using fsnotify)
 - ❌ Does NOT read existing historical log data
 
 This means:
+
 - Events are captured from the moment the collector starts
 - Historical agent activity before collector startup is not captured
 - If the collector is stopped, events during downtime are not recovered
@@ -84,14 +86,15 @@ A backfill feature is planned for future releases to address these limitations:
 devlog-collector backfill [options]
   --agent <name>        # Specific agent (copilot, claude, cursor)
   --from <date>         # Start date for historical collection
-  --to <date>           # End date for historical collection  
+  --to <date>           # End date for historical collection
   --dry-run             # Preview what would be collected
 
 # Or as a startup flag
 devlog-collector start --backfill --backfill-days=7
 ```
 
 **Use cases for historical collection:**
+
 - Initial setup with existing context from past sessions
 - Gap recovery after collector downtime or system restarts
 - Historical analysis of past AI agent activities
@@ -113,20 +116,20 @@ Example configuration:
   "backendUrl": "https://api.devlog.io",
   "apiKey": "${DEVLOG_API_KEY}",
   "projectId": "my-project",
-  
+
   "collection": {
     "batchSize": 100,
     "batchInterval": "5s",
     "maxRetries": 3,
     "retryBackoff": "exponential"
   },
-  
+
   "buffer": {
     "enabled": true,
     "maxSize": 10000,
     "dbPath": "~/.devlog/buffer.db"
   },
-  
+
   "agents": {
     "copilot": {
       "enabled": true,
@@ -141,7 +144,7 @@ Example configuration:
       "logPath": "auto"
     }
   },
-  
+
   "logging": {
     "level": "info",
     "file": "~/.devlog/collector.log"

packages/collector/README.md

@@ -5,6 +5,7 @@ This directory contains end-to-end integration tests for the Devlog Collector.
 ## Overview
 
 Integration tests verify that all components work correctly together:
+
 - Agent adapters (log parsing)
 - File system watcher (monitoring)
 - HTTP client (batching, retry)
@@ -14,60 +15,72 @@ Integration tests verify that all components work correctly together:
 ## Test Scenarios
 
 ### 1. `TestEndToEnd_CopilotLogParsing`
+
 Verifies the complete flow from Copilot log file to backend API.
 
 **What it tests**:
+
 - Log file parsing with Copilot adapter
 - Event extraction and formatting
 - HTTP client batching and sending
 - Backend API integration
 - Data integrity through the pipeline
 
 **Expected behavior**:
+
 - 2 events parsed from sample log
 - All events reach backend
 - Event metadata preserved (agent ID, type, file path)
 
 ### 2. `TestEndToEnd_OfflineBuffering`
+
 Verifies offline buffering when backend is unavailable.
 
 **What it tests**:
+
 - Detection of backend failures
 - Automatic buffering to SQLite
 - Event persistence across restarts
 - Automatic retry when backend recovers
 - Buffer cleanup after successful send
 
 **Expected behavior**:
+
 - Events buffered when backend down (503)
 - Events retrieved from buffer intact
 - Events sent successfully when backend up
 - Buffer cleared after send
 
 ### 3. `TestEndToEnd_LogRotation`
+
 Verifies handling of log file rotation.
 
 **What it tests**:
+
 - Processing events from initial file
 - Detection of file rotation
 - Processing events from new file
 - No data loss during rotation
 
 **Expected behavior**:
+
 - Events from both files processed
 - Rotation handled gracefully
 - No duplicate or missed events
 
 ### 4. `TestEndToEnd_HighVolume`
+
 Verifies performance with many events.
 
 **What it tests**:
+
 - Parsing 100 events efficiently
 - Batching optimization
 - Memory management
 - Throughput
 
 **Expected behavior**:
+
 - 100/100 events processed (100% success)
 - Processing completes in <5 seconds
 - No memory leaks
@@ -91,6 +104,7 @@ go test ./internal/integration -short
 ## Test Environment
 
 Each test creates an isolated environment:
+
 - Temporary directory (auto-cleanup)
 - Mock HTTP backend
 - Real components (minimal mocking)
@@ -116,7 +130,7 @@ func TestEndToEnd_YourScenario(t *testing.T) {
     // Initialize components
     registry := adapters.DefaultRegistry("test-project")
     adapter := adapters.NewCopilotAdapter("test-project")
-    
+
     // ... rest of setup
 
     // Write test log files
@@ -142,17 +156,20 @@ func TestEndToEnd_YourScenario(t *testing.T) {
 ## Debugging Failed Tests
 
 ### Enable verbose logging
+
 ```go
 log := logrus.New()
 log.SetLevel(logrus.DebugLevel)
 ```
 
 ### Check test output
+
 ```bash
 go test ./internal/integration -v 2>&1 | tee test.log
 ```
 
 ### Inspect temp files
+
 ```go
 // Add this to prevent cleanup
 tmpDir := t.TempDir()
@@ -163,16 +180,19 @@ t.Logf("Test directory: %s", tmpDir)
 ## Common Issues
 
 **Events not received by backend**:
+
 - Check batching delay (increase wait time)
 - Verify log format matches adapter expectations
 - Check mock server handler logic
 
 **Buffer not storing events**:
+
 - Ensure SendSingleEvent used (not SendEvent)
 - Verify backend returns failure status
 - Check buffer configuration
 
 **Timing issues**:
+
 - Increase sleep durations
 - Use polling instead of fixed delays
 - Check debounce settings
@@ -189,6 +209,7 @@ For continuous integration:
 ```
 
 For faster CI (skip slow tests):
+
 ```bash
 go test ./internal/integration -short
 ```
@@ -198,7 +219,7 @@ go test ./internal/integration -short
 Expected performance on modern hardware:
 
 - Log parsing: ~5,000 events/second
-- HTTP batching: ~1,000 events/second  
+- HTTP batching: ~1,000 events/second
 - Buffer operations: <1ms per event
 - End-to-end latency: <100ms per event
 
@@ -211,6 +232,7 @@ Expected performance on modern hardware:
 ## Support
 
 For issues with integration tests:
+
 1. Check test output for specific failures
 2. Enable debug logging
 3. Verify component configurations