* fix(feishu): tighten allowlist id matching
* fix(feishu): address review follow-ups
* changelog: note Feishu allowlist canonicalization tightening (#66021)
* fix(feishu): collapse typed wildcard allowlist aliases to bare wildcard
Previously normalizeFeishuTarget folded chat:* / user:* / open_id:* /
dm:* / group:* / channel:* down to '*', so those entries acted as
allow-all. The new typed canonicalization was producing literal keys
(chat:*, user:*, ...) that never matched any sender, silently
flipping those configs from allow-all to deny-all. Restore the prior
behavior by collapsing a wildcard value to '*' inside
canonicalizeFeishuAllowlistKey.
---------
Co-authored-by: Devin Robison <drobison@nvidia.com>
* fix(stream): tighten voice stream ingress guards
* fix(stream): address review follow-ups
* fix(stream): normalize trusted proxy ip matching
* changelog: note voice-call media-stream ingress guard tightening (#66027)
* fix(stream): require non-empty trusted proxy list before honoring forwarding headers
Without an explicit trusted proxy list, the prior gate treated every
remote as 'from a trusted proxy', so enabling trustForwardingHeaders
let any direct caller spoof X-Forwarded-For / X-Real-IP and rotate the
resolved IP per request to evade maxPendingConnectionsPerIp. Require
trustedProxyIPs to be non-empty AND match the remote before trusting
forwarding headers.
---------
Co-authored-by: Devin Robison <drobison@nvidia.com>
* move active memory into prompt prefix
* document active memory prompt prefix
* strip active memory prefixes from recall history
* harden active memory prompt prefix handling
* hide active memory prefix in leading history views
* strip hidden memory blocks after prompt merges
* preserve user turns in memory recall cleanup
* feat(telegram): expose forum topic names in agent context
Telegram Bot API does not provide a method to look up forum topic names
by thread ID. This adds an in-memory LRU cache that learns topic names
from service messages (forum_topic_created, forum_topic_edited,
forum_topic_closed, forum_topic_reopened) and seeds from
reply_to_message.forum_topic_created as a fallback for pre-existing
topics.
The resolved topic name is surfaced as:
- TopicName in MsgContext (available to {{TopicName}} in templates)
- topic_name in the agent prompt metadata block
- topicName in plugin hook event metadata
Includes unit tests for the topic-name-cache module (11 tests including
eviction and read-recency).
Known limitation: cache is in-memory only; after a restart it falls back
to the creation-time name until a rename event is observed.
* refactor(telegram): distill topic name flow
* fix: expose telegram topic names in agent context (#65973) (thanks @ptahdunbar)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
* fix(bluebubbles): lazy refresh Private API cache on send to prevent silent reply threading degradation (#43764)
When the 10-minute server info cache expires, sends requesting reply
threading or effects silently degrade to plain messages. Add a lazy
async refresh of the cache in the send path when Private API features
are needed but status is unknown, preserving graceful degradation if
the refresh fails.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(bluebubbles): apply lazy Private API refresh to attachment sends and add missing test coverage (#43764)
Attachment sends had the same cache-expiry bug as text sends: when the
10-minute Private API status cache TTL expired, reply threading metadata
was silently dropped. Apply the same lazy-refresh pattern from send.ts.
Also add the missing "refresh succeeds with private_api: false" test case
for both send.ts and attachments.ts — proves effects throw and reply
threading degrades without the "unknown" warning when the API is explicitly
disabled.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* chore: update no-raw-channel-fetch allowlist for test-harness line shift
Adding fetchBlueBubblesServerInfo to the probe mock module shifted
globalThis.fetch in test-harness.ts from line 128 to 130.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Lobster <lobster@shahine.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
