This is a comment left during a code review.
Path: src/telegram/bot-message-dispatch.ts
Line: 672-680

Comment:
**`"always"` policy still suppresses errors via cooldown**

`shouldSuppressTelegramError` is called unconditionally for both `"always"` and `"once"` policies. When policy is `"always"`, the intent is that every error surfaces — but because the cooldown check runs regardless, the first error for a given `chatId` gets recorded, and all subsequent errors within the 4-hour window are silently dropped even though the user explicitly asked for `"always"`.

The guard should only apply when policy is `"once"`:

```suggestion
          if (
            errorPolicy.policy === "once" &&
            shouldSuppressTelegramError({
              chatId,
              cooldownMs: errorPolicy.cooldownMs,
              errorMessage: String(err),
            })
          ) {
            return;
          }
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/telegram/error-policy.ts
Line: 122-126

Comment:
**`errorMessage` stored but never used for identity comparison**

The PR description promises that only "repeated identical errors" are suppressed. However, `shouldSuppressTelegramError` never compares the incoming `errorMessage` against `entry.errorMessage` — it suppresses **any** error that arrives within the cooldown window, regardless of type.

In practice: if a chat first sees a `429` rate-limit error, then shortly afterward encounters an auth/connection failure, that second (different, potentially more actionable) error is silently dropped for up to 4 hours.

To match the documented semantics, the comparison needs to incorporate error identity:

```suggestion
  // Check if we're still within cooldown period for the same error
  if (
    now - entry.lastErrorTime < cooldownMs &&
    entry.errorMessage === errorMessage
  ) {
    // Within cooldown and same error - suppress
    return true;
  }
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/telegram/error-policy.ts
Line: 12

Comment:
**Unbounded in-memory growth in `errorCooldownStore`**

`errorCooldownStore` is a module-level `Map` that is never pruned. Every unique `chatId` that ever triggers an error is permanently retained for the lifetime of the process. In a long-running bot serving many chats this will accumulate silently.

Consider evicting stale entries — the information needed is already present (`lastErrorTime`). A simple approach is to delete the entry when the cooldown has expired and the error is being let through:

```ts
// After the "cooldown expired" branch:
errorCooldownStore.set(chatIdStr, { lastErrorTime: now, errorMessage });
// or, at the start of shouldSuppressTelegramError, evict all expired entries
// periodically (e.g. every N calls) to bound memory usage.
```

Alternatively, cap the Map size or use a TTL-based structure.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/config/zod-schema.providers-core.ts
Line: 82

Comment:
**`TelegramTopicSchema` has `errorPolicy` but no `errorCooldownMs`**

`TelegramGroupSchema` and `TelegramDirectSchema` both add `errorCooldownMs` alongside `errorPolicy`, but `TelegramTopicSchema` receives only `errorPolicy`. A user who sets `errorPolicy: "once"` at the topic level has no way to tune the cooldown window.

Additionally, `resolveTelegramErrorPolicy` in `error-policy.ts` does not read topic-level configs at all — so even the `errorPolicy` field on `TelegramTopicSchema` is silently ignored at runtime. This should either be wired up in the resolver or the field should be removed from the schema to avoid misleading users.

How can I resolve this? If you propose a fix, please make it concise.