#!/usr/bin/env bash
# Telegram-Bot Watchdog (KAR-297).
# Prueft via Telegram-API ob Bot-Token gueltig + responsive, PLUS ob der Bot-
# Prozess selbst lebt. Bei wiederholtem Fail: echter Telegram-Alert (nicht nur Log).
set -euo pipefail

# 09.09.2026: Kanonischer Token liegt seit der User-Migration unter /home/aria.
# Der /root-Token wurde bewusst deaktiviert (Doppel-Poller-Fix, KAR-1044).
TOKEN_FILE="/home/aria/.claude/channels/telegram/.env"
[ -f "$TOKEN_FILE" ] || TOKEN_FILE="/root/.claude/channels/telegram/.env"
LOG_FILE="/root/aria/logs/telegram-watchdog.log"
mkdir -p "$(dirname "$LOG_FILE")"

# 12.08.2026 Watchdog-Incident-Fix (brain/02-Wissen/watchdog-incident-2026-08-12.md):
# zwei Befunde in diesem Skript, read-only als aria verifiziert.
# (1) IN_USE_DIR zeigte auf /root/.claude/channels/telegram/.in_use — dieser Pfad hat
#     NIE existiert (weder vor noch nach der 14.07.-Migration; das aktuelle Plugin
#     kennt kein .in_use-Verzeichnis mehr). Der Check lief seither immer auf den
#     0-Fallback, ohne je etwas Reales zu pruefen — stiller Blindflug, kein Fehler,
#     aber auch kein Signal. Ersetzt durch eine echte Pruefung: lebt der in bot.pid
#     verzeichnete Bot-Prozess wirklich? Das schliesst GENAU die Luecke, die Kais
#     benannt hat ("Prozess laeuft" wurde nie geprueft, nur "API antwortet").
# (2) Es gab bislang KEINEN Failure-Counter und KEINEN echten Telegram-Alert bei
#     Fail — nur eine Log-Zeile + ein audit()-Eintrag, den niemand aktiv ansieht.
#     Jetzt: persistenter Zaehler ueber Skript-Laeufe hinweg, Alarm erst nach 3
#     aufeinanderfolgenden Fails (~15 Min bei 5-Min-Timer) — vermeidet Alarm bei
#     einem einzelnen transienten Netzwerk-Wackler, sendet aber verlaesslich bei
#     echtem Ausfall statt nur still zu loggen.
# NICHT implementiert (bewusst, siehe Vollbefund): ein echtes "kam die Nachricht
# in der aktiven Session an"-Signal ueber Telegrams getUpdates(). Ein externer
# getUpdates-Call auf dasselbe Bot-Token kann den laufenden Long-Poll des Plugins
# mit "409 Conflict" aus der Bahn werfen — der Check wuerde den Ausfall erzeugen,
# den er verhindern soll. aria_chat_log (die andere denkbare Quelle) ist seit
# 06.08. leer (KAR-955, ungeloest) und wuerde permanent falschen Alarm ausloesen.
FAIL_COUNT_FILE="/tmp/aria-telegram-watchdog-fail-count"
ALERT_THRESHOLD=3

NOW="$(date -Iseconds)"

alert_kais() {
    # Bestmoeglicher Alert-Versuch ueber denselben Bot — kann selbst fehlschlagen,
    # wenn genau das Bot-Token/API kaputt ist. Deshalb zusaetzlich die Log-Zeile.
    local msg="$1"
    if [ -n "${TOKEN:-}" ]; then
        curl -s --max-time 10 -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
            -d chat_id="1164395546" -d text="$msg" > /dev/null 2>&1 || true
    fi
}

fail_step() {
    # $1 = Kurzgrund fuer Log + Alert
    local reason="$1"
    local count
    count=$(cat "$FAIL_COUNT_FILE" 2>/dev/null || echo 0)
    count=$((count + 1))
    echo "$count" > "$FAIL_COUNT_FILE"
    echo "[$NOW] FAIL ($count/$ALERT_THRESHOLD): $reason" >> "$LOG_FILE"
    if [ "$count" -ge "$ALERT_THRESHOLD" ]; then
        alert_kais "🔴 Telegram-Watchdog: ${count}x in Folge fehlgeschlagen — ${reason}. Bot evtl. offline. journalctl -u aria-telegram-watchdog.service pruefen."
        # Zaehler NICHT zuruecksetzen — sonst spammt jeder Timer-Tick erneut ab
        # Schwelle. Reset erst bei echtem Erfolg (siehe unten).
    fi
}

if [ ! -f "$TOKEN_FILE" ]; then
    echo "[$NOW] FAIL: no token file at $TOKEN_FILE" >> "$LOG_FILE"
    exit 1
fi

TOKEN=$(grep -E "^TELEGRAM_BOT_TOKEN=" "$TOKEN_FILE" | cut -d'=' -f2- | tr -d '"' | head -1)
if [ -z "$TOKEN" ]; then
    echo "[$NOW] FAIL: TELEGRAM_BOT_TOKEN empty" >> "$LOG_FILE"
    exit 1
fi

# Signal 1: Call getMe — Bot-API erreichbar?
RESP=$(curl -s --max-time 10 "https://api.telegram.org/bot${TOKEN}/getMe" || echo '{"ok":false,"error":"network"}')
OK=$(echo "$RESP" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('ok'))" 2>/dev/null || echo "False")

if [ "$OK" != "True" ]; then
    echo "[$NOW] FAIL Bot getMe returned: $RESP" >> "$LOG_FILE"
    python3 - <<PYEOF
import sys
sys.path.insert(0, "/root/aria/lib")
from aria_audit import audit
audit("aria-telegram-watchdog", "bot_unreachable", target_kind="telegram_bot", payload={"response": """$RESP"""[:500]}, status="error", error="getMe_failed")
PYEOF
    fail_step "getMe unreachable"
    exit 1
fi
USERNAME=$(echo "$RESP" | python3 -c "import json,sys; d=json.load(sys.stdin); print(d.get('result',{}).get('username','?'))" 2>/dev/null)

# Signal 2: lebt der Bot-Prozess wirklich? (schliesst die "intern haengend, aber
# getMe antwortet trotzdem" Luecke — getMe fragt Telegrams Server, nicht unseren
# Prozess. bot.pid wird vom Plugin selbst geschrieben, home-first mit root-Fallback
# fuer den (unwahrscheinlichen) Fall, dass dieses Skript je wieder gegen die
# root-Welt liefe.)
BOT_PID_FILE="/home/aria/.claude/channels/telegram/bot.pid"
[ -f "$BOT_PID_FILE" ] || BOT_PID_FILE="/root/.claude/channels/telegram/bot.pid"
PROCESS_OK=0
if [ -f "$BOT_PID_FILE" ]; then
    BOT_PID=$(cat "$BOT_PID_FILE" 2>/dev/null | tr -d '[:space:]')
    if [ -n "$BOT_PID" ] && ps -p "$BOT_PID" -o comm= 2>/dev/null | grep -qE "^(bun|node)"; then
        PROCESS_OK=1
    fi
fi

if [ "$PROCESS_OK" = "1" ]; then
    echo "[$NOW] OK Bot @${USERNAME} reachable, Prozess PID $BOT_PID lebt" >> "$LOG_FILE"
    rm -f "$FAIL_COUNT_FILE"
    exit 0
else
    echo "[$NOW] OK Bot @${USERNAME} reachable, ABER Bot-Prozess (bot.pid=$BOT_PID_FILE) nicht auffindbar/tot" >> "$LOG_FILE"
    fail_step "getMe OK aber Bot-Prozess tot (moeglicher interner Hang)"
    exit 1
fi