7 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
nanobot	ded5d4d8ed	docs: deployment guide from Camellia experience	2026-07-28 14:20:26 +08:00
nanobot	d5d6c76a93	fix: raise error when Telegram bot not running instead of silently dropping messages ... When the outbound dispatcher processes recovery notifications before the Telegram bot is fully started, the send() method silently returned, causing the notification to be lost. Now it raises RuntimeError so _send_with_retry will retry until the bot is ready.	2026-07-28 14:17:34 +08:00
nanobot	79a0fd8ed0	fix: capture pending_user_turn before _restore_runtime_checkpoint clears it ... _restore_runtime_checkpoint() clears both the runtime_checkpoint and pending_user_turn flags (lines 1966-1967). recover_stale_sessions() checked had_pending AFTER calling it, so had_pending was always False when a checkpoint existed. This meant the re-publish of the last user message never happened — the user got a notification but the interrupted turn was never re-triggered.	2026-07-28 14:13:23 +08:00
nanobot	206ab0943c		2026-07-28 14:06:35 +08:00
nanobot	a3bf5aee2d	feat: retry channel startup on transient failures (max 5 attempts, exponential backoff) ... Previously, a single transient network error during channel startup (e.g., proxy blip causing Telegram get_me() to fail) would leave the channel permanently dead until the next gateway restart. Now _start_channel retries up to 5 times with exponential backoff starting at 2s (2s, 4s, 8s, 16s, 32s = ~62s total max wait).	2026-07-28 12:15:56 +08:00
nanobot	417e2f19d5	feat: add deploy/rollback supervisor script ... Git-checkout-based deployment with health checks and automatic rollback. Usage: deploy.sh <commit> | deploy.sh rollback | deploy.sh status	2026-07-27 21:57:34 +08:00
nanobot	99b86a22c8	feat: recover stale sessions on gateway startup ... Scan all session files on startup and recover any with stale turn state (pending_user_turn or runtime_checkpoint metadata) left from a previous crash or restart. Previously this only happened lazily when a new message arrived for the affected session. - Add SessionManager.list_session_keys() to enumerate session keys from disk - Add AgentLoop.recover_stale_sessions() to scan and recover all sessions - Call recover_stale_sessions() during gateway startup in _run_gateway	2026-07-27 21:27:29 +08:00