Development logs flooded with polling requests, making debugging difficult

[leoric-crown]

Problem Description

After the successful Socket.IO removal in #514, the HTTP polling architecture is generating excessive log noise that significantly impacts development debugging. Every 1-2 second polling cycle creates multiple log entries, making it challenging to spot actual application events.

Current Log Output Example

archon-ui      | 🔄 [VITE PROXY] Forwarding: GET /api/health to http://archon-server:8181/api/health
archon-ui      | 🔄 [VITE PROXY] Forwarding: GET /api/projects to http://archon-server:8181/api/projects
archon-ui      | 🔄 [VITE PROXY] Forwarding: GET /api/agent-chat/sessions/18ca3076-081d-4fa2-86c5-b6a5f5c4039f/messages to http://archon-server:8181/api/agent-chat/sessions/18ca3076-081d-4fa2-86c5-b6a5f5c4039f/messages
[... repeats every 1-2 seconds ...]

Impact on Development Experience

• Harder to debug application issues - Real events get buried in polling noise
• Log monitoring becomes tedious - Takes effort to spot actual errors or important events
• Reduced development productivity - Developers spend time scrolling through repetitive logs
• Scales poorly - More polling endpoints increase the noise

Root Causes

1. Vite proxy logging - Every polling request logs a forwarding message (vite.config.ts:305)
2. Backend polling logs - Despite #514 claiming to move these to DEBUG level, some may still be INFO
3. High polling frequency - 1-2s intervals generate frequent noise

Proposed Solutions

Option 1: Environment-based proxy logging

• Only log Vite proxy requests when VITE_DEBUG_PROXY=true
• Default to quieter proxy logging in development

Option 2: Log level differentiation

• Move all polling-related logs to DEBUG level
• Separate "user action logs" (INFO) from "background polling logs" (DEBUG)

Option 3: Smart filtering

• Log only failed requests or first/last requests in polling sequences
• Suppress repetitive successful polling logs

Context

• The Socket.IO removal in #514 was architecturally correct and improved performance
• HTTP polling is the right solution, but could use better development ergonomics
• This affects all developers working on the project
• Issue exists in both Docker and local development environments

Acceptance Criteria

• [ ] Development logs show actual application events more clearly
• [ ] Polling requests create less noise during normal development
• [ ] Failed requests and errors are still clearly visible
• [ ] Solution works in both Docker and local development
• [ ] Developers can still enable verbose logging when needed for debugging

Priority: Medium (DX improvement)

[coleam00]

I agree it is too much! Thanks for making an issue for this.

[Wirasm]

This is by design for now and was not a priority during the refactor, the goal is to remove logfire and replace logging with structlog, tis a bigger refactor and not an easy solve

[leoric-crown]

I think this issue can be closed? Not sure when the change came in but logs seem much more manageable now?