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
Address review feedback that the capability checks were broader than the
documented per-model matrix:
- Drop the extreme aspect ratios (1:4, 4:1, 1:8, 8:1) from the Flash
allow-list. They are only documented for 3.1 Flash / Flash Lite, so the
global set could send an unsupported ratio to 2.5 Flash Image or 3.1 Pro
Image. Keep the ratios common to every Flash image model.
- Identify imageSize support positively via "gemini-3" instead of excluding
"2.5". The old predicate also matched gemini-2.0-flash-preview-image-
generation, which (with the default 1K size) altered that model's request
shape even though only Gemini 3+ image models accept a configurable size.
Add tests for the gemini-2.0 image-size drop and the extreme-ratio drop.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Gemini Flash image path (`generateContent`) dropped both `aspect_ratio`
and `image_size`: `generate()` never forwarded them and
`_generate_gemini_flash` did not accept them, so every request fell back to
1:1 / input-matched output. The Imagen path was unaffected.
Forward the hints and emit them under
`generationConfig.responseFormat.image` per the current Gemini API. Aspect
ratio is validated against the accepted set; `imageSize` is validated against
{512,1K,2K,4K} and only sent to Gemini 3+ image models, since
`gemini-2.5-flash-image` supports only `aspectRatio`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Addresses automated review: document that the guard is an intentional hard group-only switch (allowlisted DMs blocked by design) and that str() guards a None sender_id. Comment-only.
Co-Authored-By: Claude <noreply@anthropic.com>
In group chats, prefix the outbound markdown reply with an H1 naming the sender (# @<nick>) so the addressed user can spot it in a busy group. Private replies are sent verbatim.
Visual only: DingTalk markdown robot messages do not push real @ notifications (that would require staffId plumbing and a different message type). sender_name is read from OutboundMessage.metadata, which the agent loop already propagates from inbound metadata.
Co-Authored-By: Claude <noreply@anthropic.com>
Add a `disable_private_chat` config flag (JSON alias `disablePrivateChat`,
default False) to the DingTalk channel. When enabled, any non-group (1:1)
message is rejected with a Chinese notice directing the user to group chat
("该机器人未开启私聊，请在群聊中与我对话。") before permission/pairing logic
runs, so even allowlisted senders are redirected. Group messages are
unaffected.
Co-Authored-By: Claude <noreply@anthropic.com>
Before this change, idle compaction is triggered every 1 second
if the incoming message stream is idle.
When triggered, it enumerates all session files, loads and parses them,
and then checks their expiration.
This becomes too CPU-intensive, especially on low-power devices like Raspberry Pi.
It's unlikely that you actually need to compact every second over the long time.
This change adds a configurable throttling for idle-compaction.
Default behavior is unchanged.
Reset both the recovered segments and retry budget whenever injected input starts a new logical answer. Cover fatal tool-error boundaries and rename the prompt test module so pytest can collect the full suite.
nanobot
chengyongruandchengyongru
yu-xin-candXubin Ren
chengyongruandXubin Ren
Andrew KhmylovandXubin Ren
shixi-liandXubin Ren
amplifierplusandXubin Ren
KDBandXubin Ren
santhrealandXubin Ren