we-mp-rss-troubleshooting

name we-mp-rss-troubleshooting title we-mp-rss Docker Troubleshooting description Diagnose and fix common we-mp-rss Docker container issues: container exited state, Docker Desktop not running, proxy misconfiguration, QR code auth failure, cookie expiry, cascade worker registration failure, ContentTaskQueue stuck (Playwright anti-bot → api mode fix), dual-DB feed sync, extractor hanging on contentless articles (placeholder fallback fix), web.py API endpoint/response rewrite (appmsgpublish→appmsg, app_msg_list format), and cron job failures. version 1.2.0 author Hermes Agent tags ["docker","we-mp-rss","wechat","cron","troubleshooting"] we-mp-rss Docker Troubleshooting Trigger: When wechat-mp-rss-extractor cron fails with "Connection refused", "Cannot reach we-mp-rss", when the Docker container is in an unexpected state, or when the extractor produces 0 new files despite the container responding HTTP 200. Common Failure Patterns 1. Docker Desktop Not Running (most frequent) Symptoms: Cannot connect to the Docker daemon at unix:///Users/jinguo/.docker/run/docker.sock or Cannot reach we-mp-rss at http://localhost:8001: <urlopen error [Errno 61] Connection refused> Cause: Docker Desktop was not running when the cron job fired. The we-mp-rss container cannot start without Docker. Fix: # Start Docker Desktop open -a Docker # Wait for it to initialize sleep 15 # Verify Docker is available docker info >/dev/null 2>&1 && echo "Docker is running" 2. Container in Exited State Symptoms: we-mp-rss Exited (255) 15 seconds ago ghcr.io/rachelos/we-mp-rss:latest Cause: Container crashed or was stopped. Exit code 255 typically means the process terminated abnormally. Diagnosis: docker logs we-mp-rss 2>&1 | tail -30 Fix: docker restart we-mp-rss sleep 10 curl -s -o /dev/null -w "%{http_code}" http://localhost:8001/rss? limit =1 # Should return 200 3. Service Running but Slow to Respond Symptoms: Cron runs but extractor gets connection refused even after docker restart . Cause: Container is starting up but the web server hasn't bound port 8001 yet. Fix: # Wait and retry sleep 10 curl -s -o /dev/null -w "%{http_code}" http://localhost:8001/rss? limit =1 3b. Port Mapping Mismatch — Connection reset by peer Symptoms: curl -v http://localhost:8001/ shows Connected to localhost then Recv failure: Connection reset by peer . docker ps shows the port mapping but the service is unreachable. Inside the container, urllib to localhost:8001 works but localhost:3000 is refused. Cause: The -p flag mapped host:8001 → container:3000 but the Node.js server listens on port 8001 (not 3000). The container's internal listening port is 8001 — confirmed by docker port we-mp-rss showing 3000/tcp -> 0.0.0.0:8001 (wrong direction) vs the correct 8001/tcp -> 0.0.0.0:8001 . Fix: Always use -p 8001:8001 (not -p 8001:3000 ). Verify with: docker port we-mp-rss # Expected: 8001/tcp -> 0.0.0.0:8001 # Quick health check (from host) curl -s -o /dev/null -w "%{http_code}" http://localhost:8001/rss? limit =1 # Should return 200 # Inside container test (if curl to host fails) docker exec we-mp-rss python3 -c "import urllib.request; print(urllib.request.urlopen('http://localhost:8001/rss?limit=1', timeout=5).read()[:50])" Reference: references/2026-07-02-proxy-empty-port-browser-fix.md — full recovery transcript including proxy-empty-variant, port mapping mismatch, and Playwright browser_type fix. Cron Job Pre-Run Checklist Before running wechat-mp-rss-extractor.py : # 1. Ensure Docker is running docker info >/dev/null 2>&1 || { open -a Docker; sleep 15; } # 2. Ensure container is running docker ps --filter "name=we-mp-rss" --filter "status=running" | grep we-mp-rss # If not running: docker restart we-mp-rss && sleep 10 # 3. Verify service responds curl -s -o /dev/null -w "%{http_code}" http://localhost:8001/rss? limit =1 # Should return 200 # 4. Run extractor source ~/.wiki-cron.env export PATH= " $PATH :/Users/jinguo/Library/Python/3.14/bin" cd ~/wiki && python3 scripts/wechat-mp-rss-extractor.py --latest=10 4. DB Mismatch After Container Recreate Symptoms: After docker compose down && up -d , the web UI shows "共 0 条" (no subscriptions) even though the volume mounted correctly. Root Cause: The docker-compose-sqlite.yaml configures DB=sqlite:///data/we_mp_rss.db but the real data may be in db.db (created by a previous version or config). The new container creates a fresh we_mp_rss.db while the subscriptions remain in db.db . Fix: # Check which DB has data sqlite3 /Users/jinguo/data/we_mp_rss.db "SELECT COUNT(*) FROM feeds;" sqlite3 /Users/jinguo/data/db.db "SELECT COUNT(*) FROM feeds;" # Restore data (backup first) cp /Users/jinguo/data/we_mp_rss.db /Users/jinguo/data/we_mp_rss.db.bak cp /Users/jinguo/data/db.db /Users/jinguo/data/we_mp_rss.db docker restart we-mp-rss 5. Broken PASSWORD Line in docker-compose YAML Symptoms: Login returns "Could not validate credentials" for any password. Root Cause: The compose file has a merged line like PASSWORD=*** - GATHER.CONTENT=True — two env vars concatenated. The running container stores the literal broken value as the password hash. Fix: Split into separate YAML lines: - PASSWORD=*** GATHER.CONTENT=True After fixing, either delete the DB to force recreation with the correct password, or restore from a known-good backup ( db.db ). 6. env_file Pattern (Recommended) Instead of hardcoding secrets in docker-compose: services: we-mp-rss: env_file: - ../.env environment: - DB=sqlite:///data/we_mp_rss.db Add .env to .gitignore . Restart to apply: docker compose -f compose/docker-compose-sqlite.yaml up -d 7. List Subscriptions via CLI curl -s http://localhost:8001/rss | grep '<title>' | grep -v 'WeRSS订阅' Verification After Scan Important: The heartbeat file is typically touched by the cron preamble ( cron-heartbeat.py touch ), so find -newer heartbeat will NOT find new files (they're older than the heartbeat). Instead, verify by: # Method 1: Count total files ls ~/wiki/raw/wechat-inbox/*.md | wc -l # Method 2: Check cron-status.log tail ~/wiki/cron-status.log # Method 3: Check most recent files ls -lt ~/wiki/raw/wechat-inbox/*.md | head -5 Environment Setup Required in cron shell (bash, non-interactive — .zshrc is NOT loaded): source ~/.wiki-cron.env export PATH= " $PATH :/Users/jinguo/Library/Python/3.14/bin" The .wiki-cron.env file contains WERSS_AK and WERSS_SK for API authentication. 4. "Alive but Stale" — Service HTTP 200 but Upstream Sync Broken (Proxy Misconfiguration) Symptoms: curl http://localhost:8001/rss?limit=1 returns HTTP 200 RSS feeds return valid XML with article entries BUT all articles' pubDate are weeks/months old (e.g., all from May when today is July) Docker logs show 成功0条 for every account in every sync cycle wechat-inbox stays at 0 new files indefinitely ⚠️ Diagnostic trap : The container's internal articles table create_time can be stale even when the RSS has current articles. These are SEPARATE data paths — the RSS endpoint generates from one source, the articles table from another. Always check the per-feed RSS endpoint directly before concluding the pipeline is stuck. # CORRECT first step — check RSS per-feed (fast, accurate) curl -s "http://localhost:8001/rss/MP_WXS_3236757533?limit=3" | grep -o '<pubDate>[^<]*</pubDate>' # If these show today's dates -> pipeline is healthy Root Cause (two variants): 127.0.0.1 loopback — HTTP_PROXY=http://127.0.0.1:10808 (points to container's own loopback, not host). Error: ProxyError('Unable to connect to proxy') . Empty proxy env — HTTP_PROXY= / http_proxy= (variable present but empty). No error logged — requests just timeout silently behind the Great Firewall. This was the 2026-07-02 failure: container rebuilt without setting proxy vars, leaving them as empty strings. Diagnosis Sequence: # Step 1: Check RSS data freshness (pick 2-3 representative accounts) for fakeid in MP_WXS_3006407565 MP_WXS_3073282833 MP_WXS_3236757533; do name=$(curl -s --connect-timeout 5 "http://localhost:8001/rss/ $fakeid ?limit=1" | grep -oE '<title>[^<]+</title>' | tail -1 | sed 's/<[^>]*>//g' ) date =$(curl -s --connect-timeout 5 "http://localhost:8001/rss/ $fakeid ?limit=1" | grep -oE '<pubDate>[^<]+</pubDate>' | head -1 | sed 's/<[^>]*>//g' ) echo " $name : $date " done # If all dates are >7 days old → upstream sync has stopped # Step 2: Check Docker logs for proxy errors docker logs we-mp-rss -- tail 200 2>/dev/null | grep -iE 'error|proxy|refused|connect' | head -10 # Step 3: Check container env vars for proxy misconfiguration docker inspect we-mp-rss --format '{{range .Config.Env}}{{println .}}{{end}}' 2>/dev/null | grep -i proxy # WRONG: HTTP_PROXY=http://127.0.0.1:10808 (container's own loopback!) # RIGHT: HTTP_PROXY=http://host.docker.internal:10808 # Step 4: Verify host.docker.internal resolves inside container docker exec we-mp-rss python3 -c "import socket; print(socket.gethostbyname('host.docker.internal'))" # Should return 192.168.65.254 (Docker Desktop's host gateway) # Step 5: Check DB for newest article date docker cp we-mp-rss:/app/data/db.db /tmp/we-mp-rss.db sqlite3 /tmp/we-mp-rss.db "SELECT title, publish_time FROM articles ORDER BY publish_time DESC LIMIT 5;" python3 -c " import sqlite3, datetime conn = sqlite3.connect('/tmp/we-mp-rss.db') for row in conn.execute('SELECT title, publish_time FROM articles ORDER BY publish_time DESC LIMIT 5'): dt = datetime.datetime.fromtimestamp(row[1]) print(f'{dt} | {row[0][:40]}') " Fix: Stop old container and recreate with corrected proxy env vars: # Stop the broken container docker stop we-mp-rss docker rm we-mp-rss # Recreate with correct proxy (host.docker.internal instead of 127.0.0.1) docker run -d \ --name we-mp-rss \ --restart unless-stopped \ -p 8001:8001 \ -v /Users/jinguo/data:/app/data \ -e USERNAME=admin \ -e PASSWORD=*** \ -e GATHER.CONTENT=True \ -e GATHER.CONTENT_MODE=web \ -e GATHER.MODEL=web \ -e GATHER.CONTENT_AUTO_CHECK=True \ -e GATHER.CONTENT_AUTO_INTERVAL=59 \ -e BROWSER_TYPE=chromium \ -e DB=sqlite:///data/we_mp_rss.db \ -e TZ=Asia/Shanghai \ -e WERSS_AK=<AK> \ -e WERSS_SK=<SK> \ -e PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple \ -e HTTP_PROXY=http://host.docker.internal:10808 \ -e HTTPS_PROXY=http://host.docker.internal:10808 \ -e http_proxy=http://host.docker.internal:10808 \ -e https_proxy=http://host.docker.internal:10808 \ -e NO_PROXY=localhost,127.0.0.1,::1,*. local \ -e no_proxy=localhost,127.0.0.1,::1,*. local \ ghcr.io/rachelos/we-mp-rss:latest # Wait for startup sleep 15 # Verify sync is working curl -s --connect-timeout 5 "http://localhost:8001/rss?limit=30&offset=0" | grep -oE '<pubDate>[^<]+</pubDate>' | head -3 # Should show recent dates (today or yesterday) Data safety: The -v /Users/jinguo/data:/app/data bind mount preserves the SQLite DB across container recreation. All feed subscriptions and article history are retained. Verification after fix: # Check that sync_time updates (run after the first sync cycle completes) docker cp we-mp-rss:/app/data/db.db /tmp/we-mp-rss.db sqlite3 /tmp/we-mp-rss.db "SELECT mp_name, datetime(sync_time, 'unixepoch') FROM feeds ORDER BY sync_time DESC LIMIT 5;" # Should show recent timestamps 5. WeChat Session Token Expired (after proxy fix) Symptoms: Proxy is fixed (no more Connection refused errors) But Docker logs show Invalid Session, stop at 0 for every account Web UI "授权管理" page shows Token 到期时间 in the past 成功0条 continues despite proxy working cascade_task_allocations table shows 273+ entries with status=timeout (error: "任务超时（>30分钟）") Critical Pitfall: Redis Caches Old Token