Optimize update_combined_blacklist.yml to reduce timeout aborts

[Copilot]

The workflow was hitting its 50-minute job timeout due to network contention from 15 parallel workers processing 100+ feeds. This tunes the key knobs to reduce abort frequency and improve failure visibility.

Changes

Concurrency & timeouts

• timeout-minutes: 50 → 70 (realistic buffer for slow network conditions)
• max_workers: 15 → 10 (less rate-limiting / connection contention on GitHub runners)
• Per-feed socket timeout: 25s → 22s (faster fail-fast on dead feeds)
• Main feed block (as_completed timeout): 600s → 580s
• Auto-discovered feed block timeout: 120s → 110s
• READ_LIMIT kept at 25 MB (feeds reach 35MB+)

Error visibility

• Feed fetch errors now emit a GitHub Actions ::warning annotation with exception type, making slow/broken feeds immediately visible in the Actions UI without digging through logs:

except Exception as e:
    print(f"ERR  {name}: {type(e).__name__}: {e}")
    print(f"::warning file=update_combined_blacklist.yml::Feed fetch failed [{name}]: {type(e).__name__}: {e}")
    return name, set()

Original prompt

Optimize update_combined_blacklist.yml workflow performance to reduce timeout issues.

Current Issues

• Job timeout is 50 minutes, which is tight for processing 100+ feeds with network latency
• ThreadPoolExecutor with 15 max_workers causes network contention and rate-limiting
• Previous timeout failures reported by user

Optimization Strategy

1. Increase job timeout from 50 to 70 minutes (gives realistic buffer)
2. Reduce max_workers from 15 to 10 (better resource utilization, less contention)
3. Keep READ_LIMIT at 25MB (some IP lists reach 35MB, need headroom)
4. Optimize feed timeout handling:
   • Main feed block timeout: 600s → 580s (faster feedback if many feeds fail)
   • Auto-feed timeout: 120s → 110s (less critical, still reasonable)
   • Per-feed socket timeout: 25s → 22s (shorter timeout = quicker fail-fast)
5. Add explicit error logging for feed fetch failures to help debug slowdowns

Expected Impact

• Reduced timeout aborts during legitimate slow network conditions
• Better parallelization without overwhelming GitHub runner
• Faster failure detection on broken feeds (don't wait the full 25s)
• Still accommodates large 35MB+ IP list files

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: check meinen workflow auf fehler ob jetzt alle startet

Assistant: Ich schaue mir die Workflows in deinem Repository an und überprüfe auf Fehler.

Assistant: Lasse mich einen anderen Weg versuchen, um deine Workflows zu überprüfen:

Assistant: Jetzt schaue ich mir alle Workflows an, um auf Fehler zu prüfen:

Assistant: Nun hole ich mir die restlichen Workflows:

Assistant: Basierend auf meiner Analyse Ihrer Workflows habe ich gute Nachrichten: Alle Workflows sind syntaktisch korrekt und sollten starten. Hier ist eine Zusammenfassung:

✅ Workflow-Status

Du hast 17 Workflows im Repository:

Workflow	Schedule	Status
🔵 asn_reputation_scorer.yml	täglich 02:00 UTC	✅ OK
🔵 auto_feed_discovery.yml	wöchentlich So 04:30 UTC	✅ OK
🔵 community_ip_report.yml	Bei Issue-Labels	✅ OK
🔵 cve_to_ip_mapper.yml	täglich 04:00 UTC	✅ OK
🔵 false_positive_checker.yml	täglich 05:00, 13:00, 20:00 UTC	✅ OK
🔵 feed_health_monitor.yml	täglich 01:00 UTC	✅ OK
🔵 geo_tagger.yml	So 07:45 UTC	✅ OK
🔵 honeydb_monitor.yml	täglich 22:15 UTC	✅ OK
🔵 honeypot_monitor.yml	täglich 23:00 UTC	✅ OK
🔵 run_tests.yml	Bei Push/PR auf scripts/ & tests/	✅ OK
🔵 update_combined_blacklist.yml	alle 3 Stunden	✅ OK
+ 6 weitere Workflows	verschiedene Schedules	✅ OK

🎯 Wichtige Befunde

Keine kritischen Fehler gefunden:

• ✅ Alle YAML-Syntaxe ist gültig
• ✅ Alle Actions-Versionen sind aktuell (v4.2.2 für checkout)
• ✅ Alle cron-Schedules sind korrekt formatiert
• ✅ Alle permissions sind angemessen gesetzt
• ✅ concurrency ist überall konfiguriert

Best Practices implementiert:

• Explizite Error-Handling mit if: always()
• Retry-Logik bei Netzwerkfehlern
• False-Positive-Schutz durch false_positives_set.json
• Whitelist-Filterung durch whitelist.json (Single Source of Truth)
• Git Push-Retry-Mechanismen gegen Race Conditions

⚠️ Mögliche Laufzeitprobleme (nicht Syntax-Fehler):

Falls Workflows fehlschlagen, sind das eher externe Abhängigkeiten:

1. API-Keys fehlend?

   • HONEYDB_API_ID, HONEYDB_API_KEY
   • ABUSEIPDB_API_KEY_1/2/3

2. Netzwerk-Timeouts bei Feed-Downloads

   • ScaniteX, abuse.ch, HoneyDB können zeitweise unerreichbar sein

3. GitHub API-Limits bei auto_feed_discovery.yml

   • Bei Ratelimit wartet der Workflow 60s

Alle Workflows sollten normal starten. Möchtest du einen spezifischen Workflow manuell testen oder auslösen?

User: ja die comb da dauerte mir vorher einduchrlauf zulange da war abruch wegem time out

Assistant: Ich schau mir die update_combined_blacklist.yml genauer an, um die Timeout-Probleme zu finden.

Assistant: Okay, das combined Workflow war zu lange! Das ist ein echter Performance-Problem. Hier sind die Optimierungsmöglichkeiten:

🐌 Aktuelle Performance-Bottlenecks:

Problem	Zeile	Impact
Timeout: 50 Minuten	26	Sehr knapp! Bei 15 parallelen Feeds kann das schwierig werden
ThreadPoolExecutor: 15 Worker	478	Zu hoch → zu viele gleichzeitige Netzwerk-Requests
READ_LIMIT: 25 MB	185	Zu hoch für große Feeds (romainmarcoux hat 300k IPs)
Feed-Timeout: 600s	481	Wartet bis zum Bitter-Ende auf langsame Feeds
Auto-Discovered Timeout: 120s	599	Separat + nochmal warten

---

✅ Optimierungsempfehlung (Pull Request):

Soll ich einen PR erstellen, der folgende Verbesserungen macht?

1. Worker reduzieren: 15 → 8 (weniger gleichzeitige Requests, stabiler)
2. READ_LIMIT senken: 25 MB → 10 MB (reicht für IP...

This pull request was created from Copilot chat.