6b3ab6d6fc
BREAKING CHANGE: Storage and system scans no longer create entries in update_logs **Problem** - Storage scans were appearing on Updates page (mixed with package updates) - System scans were appearing on Updates page (mixed with package updates) - Duplicate "Scan All" entries from collective + individual logging **Root Cause** Scan handlers were calling both ReportLog() and dedicated endpoints: - reportLogWithAck → POST /api/v1/agents/:id/logs → update_logs table - This caused storage/system metrics to appear alongside package updates **Fix** Removed ALL ReportLog() calls from scan handlers: 1. handleScanUpdatesV2 (lines 44-46): Removed collective logging 2. handleScanStorage (lines 103-105): Use only ReportStorageMetrics 3. handleScanSystem (lines 189-191): Use only ReportMetrics 4. handleScanDocker (lines 269-271): Use only ReportDockerImages **Verification** - All 4 handlers have working dedicated endpoints (verified via subagent) - Routes already registered: POST /storage-metrics, POST /metrics, etc. - Frontend queries correct endpoints (verified) - No data loss: dedicated endpoints store in proper tables **Result** - Storage scans → storage_metrics table → Storage page only ✅ - System scans → system reporting → System page only ✅ - Package updates → update_logs table → Updates page only ✅ - No duplicate "Scan All" entries ✅ **Files Changed** - aggregator-agent/cmd/agent/subsystem_handlers.go: Removed 20 lines of ReportLog calls - internal/api/handlers/agents.go: Command recovery enhancements - internal/api/handlers/updates.go: Subsystem extraction logic - internal/database/queries/commands.go: GetStuckCommands query
51 lines
1.8 KiB
Plaintext
51 lines
1.8 KiB
Plaintext
## Summary: Why History Shows "SCAN" Generically
|
|
|
|
**The Confusion You See**:
|
|
- Each subsystem has its own "Scan" button (✅ correct)
|
|
- But history only shows generic "SCAN" (❌ confusing)
|
|
|
|
**The Implementation Flow**:
|
|
```
|
|
You click: "Scan Storage" button
|
|
→ UI passes: subsystem="storage" ✅
|
|
→ Backend creates: command_type="scan_storage" ✅
|
|
→ Agent runs: handleScanStorage() ✅
|
|
→ Results stored: updates=[4 items] ✅
|
|
→ History logged: action="scan" ❌ (should be "storage scan" or similar)
|
|
```
|
|
|
|
**Root Cause**:
|
|
The history table's `action` field stores only generic "scan" instead of including the subsystem context. Even though:
|
|
- Backend knows it's "scan_storage"
|
|
- UI sends subsystem parameter
|
|
- Results are subsystem-specific
|
|
|
|
**The Result**:
|
|
```
|
|
History shows unhelpful entries like:
|
|
[14:20] SCAN → Success → 4 updates found
|
|
[14:19] SCAN → Success → 461 updates found
|
|
|
|
Which subsystem found which updates? Unknown from history.
|
|
```
|
|
|
|
**This is a UX Issue, NOT a Bug**:
|
|
- ✅ Scans run for correct subsystems
|
|
- ✅ Results are accurate
|
|
- ✅ Backend distinguishes types ("scan_storage", "scan_system", "scan_docker")
|
|
- ❌ History display is generic "SCAN" instead of "Storage Scan", "System Scan", "Docker Scan"
|
|
|
|
**Why It Happened**:
|
|
- Early design had simple action types ("scan", "install", "upgrade")
|
|
- Later added docker/storage/system scans
|
|
- Database schema never evolved to include subsystem context
|
|
- History display just shows action field directly
|
|
|
|
**Files Involved**:
|
|
- ✅ Working: AgentHealth.tsx (per-subsystem scan buttons)
|
|
- ✅ Working: Backend API (creates "scan_storage", "scan_system", etc.)
|
|
- ❌ Broken: History logging (stores only "scan", not subsystem)
|
|
- ❌ Broken: History display (shows generic text, no subsystem parsing)
|
|
|
|
**Full Analysis**: `/home/casey/Projects/RedFlag/UX_ISSUE_ANALYSIS_scan_history.md`
|