The previous guard used self._running, which is False both before run()
starts and during shutdown. Tests and process_direct() dispatch messages
with _running=False, so cancelled turns there silently skipped the
checkpoint restore and lost partial context. Introduce _shutting_down,
set only by stop(), and gate the restore on it.
The re-published last user message was persisted into session history a
second time when the agent loop processed it, duplicating the user's
input. Mark the re-published InboundMessage with SKIP_USER_PERSIST_META
so should_persist_user_message() and _save_skip_for_turn() treat it as
already-persisted.
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.
_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.
recover_stale_sessions now publishes a restart notification to the user channel and re-publishes the last user message for sessions with a pending turn, so interrupted work continues automatically after a crash or restart. Also skip checkpoint restore during shutdown so pending markers survive for startup recovery.
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).
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
nanobot