Skip to content

Conversation

@Dumbris
Copy link
Contributor

@Dumbris Dumbris commented Jun 30, 2025

No description provided.

@Dumbris Dumbris merged commit a8040e5 into main Jun 30, 2025
33 checks passed
@Dumbris Dumbris deleted the bubfix/linter-fixs branch June 30, 2025 06:36
rannow pushed a commit to rannow/mcpproxy-go that referenced this pull request Sep 23, 2025
Dumbris added a commit that referenced this pull request Nov 2, 2025
Implements Issues #1, #2, #4, and #11 (Layers 1, 3, 4) from docker-recovery-improvements.md

**Issue #11: Duplicate Container Spawning Prevention**
- Layer 1 (Idempotent Creation): ensureNoExistingContainers() cleans up all existing containers before creating new ones
- Layer 3 (Distributed Locks): Per-server mutex prevents concurrent container creation races
- Layer 4 (Enhanced Health Verification): verifyContainerHealthy() checks Docker container state AND responsiveness

**Issue #1: Docker-only Filtering**
- ForceReconnectAll() now filters to only reconnect Docker-based servers
- HTTP/SSE/stdio servers are skipped, preventing unnecessary reconnections

**Issue #2: Container Health Verification**
- verifyContainerHealthy() detects frozen containers when Docker paused
- Uses docker inspect to verify container running + responsive
- Prevents skipping reconnection for zombie containers

**Issue #4: Add Recovering State**
- New StateCoreRecoveringDocker state provides UX feedback during recovery
- EventDockerRecovered triggers transition from error → recovering → launching
- Tray menu shows "Docker engine recovered - reconnecting servers..."

**Files Modified:**
- internal/upstream/core/docker.go: ensureNoExistingContainers(), GetContainerID()
- internal/upstream/core/connection.go: container lock acquisition, pre-cleanup
- internal/upstream/core/container_lock.go: NEW - distributed lock implementation
- internal/upstream/core/client.go: GetContainerID() accessor
- internal/upstream/manager.go: verifyContainerHealthy(), Docker-only filtering
- internal/upstream/managed/client.go: GetContainerID() delegation
- cmd/mcpproxy-tray/internal/state/states.go: StateCoreRecoveringDocker, EventDockerRecovered
- cmd/mcpproxy-tray/main.go: state mapping, handleDockerRecovering()
- internal/tray/connection_state.go: ConnectionStateRecoveringDocker

**Testing:**
- All upstream package tests passing (./internal/upstream/...)
- Code compiles cleanly (go build ./...)
- State machine transitions validated

**Impact:**
- Prevents duplicate container spawning during concurrent reconnections
- Eliminates resource exhaustion from orphaned containers
- Better UX - users see recovery in progress instead of errors
- Only Docker servers affected by Docker recovery (not HTTP/SSE)
technicalpickles added a commit to technicalpickles/mcpproxy-go that referenced this pull request Dec 1, 2025
Enhanced docs/oauth-zero-config.md with detailed documentation for:

1. Server States Section:
   - Connected states: ready (authenticated), connected (no token)
   - Waiting states: pending_auth (normal waiting state, not an error)
   - Transitional states: connecting, authenticating
   - Error states: disconnected, error

2. Checking Authentication Status:
   - How to use `mcpproxy auth status` command
   - Example output with emoji indicators (✅⏳❌)
   - Status meaning explanations

3. Troubleshooting Section with 4 Common Issues:

   Issue smart-mcp-proxy#1: Server Shows "Pending Auth" State
   - Symptoms: ⏳ icon in tray, pending_auth status
   - Cause: OAuth detected but user hasn't authenticated
   - Solution: Use `auth login` or tray "Authenticate" action
   - Clarification: NOT an error, intentional deferral

   Issue smart-mcp-proxy#2: Authentication Token Expired
   - Symptoms: Was working, now shows "Auth Failed"
   - Cause: OAuth token expired (1-24 hour lifetime)
   - Solution: Re-authenticate with `auth login`

   Issue smart-mcp-proxy#3: OAuth Detection Not Working
   - Symptoms: No pending_auth, just connection failures
   - Diagnosis: Check doctor output, logs, manual OAuth test
   - Common causes: Non-standard endpoints, firewall issues
   - Solution: Add explicit OAuth configuration

   Issue smart-mcp-proxy#4: OAuth Login Opens Browser But Fails
   - Symptoms: Browser opens, approval given, but still fails
   - Diagnosis: Check callback logs for authorization code
   - Common causes: Port conflict, timeout, firewall
   - Solution: Retry with debug logging

4. Diagnostic Commands Reference:
   - doctor: Quick OAuth detection check
   - auth status: View token status
   - upstream list: Check connection status
   - upstream logs: View OAuth flow logs
   - auth login --log-level=debug: Test with debug output
   - upstream list --format=json | jq: Verify OAuth config

This addresses user confusion about "Pending Auth" being displayed as an
error state. Documentation now clearly explains it's a normal waiting state
and provides step-by-step troubleshooting for all OAuth-related issues.

Related to PR smart-mcp-proxy#165: Zero-config OAuth with RFC 8707 support
Task: Update documentation for OAuth server states and troubleshooting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant