zulip: fix event queue registration for multiple monitored streams by simpliq-marvin · Pull Request #14182 · openclaw/openclaw

simpliq-marvin · 2026-02-11T16:38:59Z

Problem

When channels.zulip.streams contains multiple stream names, the Zulip plugin was registering an event queue with a narrow like:

[["stream","build"],["stream","general"],["stream","openclaw"],["stream","research"]]

Zulip narrows are ANDed, so this matches nothing (a message cannot be in multiple streams at once). This caused the default/Marvin account to stop receiving messages, while role accounts (1 stream each) continued to work.

Fix

If streams contains "*": use all_public_streams=true
If exactly 1 stream: use narrow=[["stream","<name>"]] (legacy list format)
If multiple streams: omit narrow (broad queue) and rely on existing client-side filtering

Tests

Adds a Vitest regression test covering the three cases above.

Greptile Overview

Greptile Summary

This PR fixes Zulip event queue registration when multiple monitored streams are configured: it uses all_public_streams=true for "*", uses a single-stream narrow for exactly one stream (legacy list format), and omits narrow for multiple streams while enforcing the stream allowlist client-side. It also adds new Zulip plugin implementation files (client, monitor, send/probe, config schema, normalization) plus Vitest coverage for queue registration and stream filtering, and updates docs/labeler to include Zulip.

The change integrates into the channel plugin system by providing a zulipPlugin with config + pairing + outbound delivery, a monitor loop using Zulip event queues, and shared helpers for routing/session keys and stream monitoring.

Confidence Score: 3/5

This PR is close to mergeable but has a couple of logic issues that can affect message routing and inbound gating.
Core stream registration fix looks correct and is covered by targeted tests, but there are two verified logic bugs: outbound parsing can truncate topics, and inbound mention detection uses a hardcoded agentId which can drop messages for routed agents when requireMention is enabled.
extensions/zulip/src/zulip/send.ts; extensions/zulip/src/zulip/monitor.ts

Adds a full Zulip channel plugin with: - Event queue polling with exponential backoff - Authenticated upload downloads from /user_uploads/ - Outbound file uploads via /api/v1/user_uploads - Reaction indicators (eyes → check_mark/warning) - Topic directive [[zulip_topic: <topic>]] - HTTP retry with backoff (429/502/503/504) - Full actions API (stream CRUD, user management, reactions) - Channel docs and unit tests Refs: #5163, openclaw#8365, openclaw#9643

Addresses Greptile review feedback: ensure lastEventId stays as a number type when assigned from event response data.

Zulip /register narrows are ANDed, so a narrow containing multiple stream operators matches nothing. For >1 stream, register a broad queue and rely on client-side filtering. Adds a vitest regression test for the narrow/all_public_streams behavior.

greptile-apps

_{29 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-11T16:53:22Z

extensions/zulip/src/zulip/monitor.ts

+      chatType,
+      sender: { name: senderName, id: senderId },
+    });
+
+    const to = kind === "dm" ? `user:${senderId}` : `stream:${streamName || streamId}:${topic}`;


Stream replies can break

to is built as stream:${streamName || streamId}:${topic}. When display_recipient isn’t a string, streamName stays empty and this falls back to message.stream_id (numeric). That numeric value then flows through sendMessageZulip → sendZulipStreamMessage and is used as the Zulip API to field, which this implementation treats as a stream name (not an ID). This will cause stream replies to fail / go to the wrong place for events where only stream_id is available.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/zulip/src/zulip/monitor.ts Line: 542:546 Comment: **Stream replies can break** `to` is built as ``stream:${streamName || streamId}:${topic}``. When `display_recipient` isn’t a string, `streamName` stays empty and this falls back to `message.stream_id` (numeric). That numeric value then flows through `sendMessageZulip` → `sendZulipStreamMessage` and is used as the Zulip API `to` field, which this implementation treats as a *stream name* (not an ID). This will cause stream replies to fail / go to the wrong place for events where only `stream_id` is available. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-11T16:53:23Z

extensions/zulip/src/zulip/client.ts

+  if (params.streams?.includes("*")) {
+    body.set("all_public_streams", "true");
+  } else if (params.streams && params.streams.length > 0) {
+    // IMPORTANT: Zulip narrow filters are ANDed.
+    // A narrow like [["stream","a"],["stream","b"]] matches nothing.
+    // So:
+    // - if exactly one stream is requested, use a stream narrow
+    // - if multiple streams are requested, register a broad queue and filter client-side
+    //   (we already drop messages outside account.streams in monitor.ts).


No client-side stream filter

For streams.length > 1, /register intentionally omits narrow and relies on “existing client-side filtering” (“we already drop messages outside account.streams in monitor.ts”). However extensions/zulip/src/zulip/monitor.ts doesn’t filter inbound stream messages against account.streams at all (it only uses account.streams for queue registration). With multiple streams configured, this will process messages from any stream the bot can see, which is a behavior regression vs the intended “monitor only these streams” semantics.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/zulip/src/zulip/client.ts Line: 281:289 Comment: **No client-side stream filter** For `streams.length > 1`, `/register` intentionally omits `narrow` and relies on “existing client-side filtering” (“we already drop messages outside account.streams in monitor.ts”). However `extensions/zulip/src/zulip/monitor.ts` doesn’t filter inbound stream messages against `account.streams` at all (it only uses `account.streams` for queue registration). With multiple streams configured, this will process messages from *any* stream the bot can see, which is a behavior regression vs the intended “monitor only these streams” semantics. How can I resolve this? If you propose a fix, please make it concise.

When monitoring multiple streams we must omit Zulip /register narrow (narrows are ANDed), which results in a broad event queue. Ensure we still respect channels.zulip.streams by filtering inbound stream messages in monitor.ts. Also resolve missing stream names via /streams/{id} so outbound replies don't fall back to numeric stream ids.

simpliq-marvin · 2026-02-11T18:06:32Z

Addressed Greptile concerns:

Broad queue filtering: when monitoring multiple streams we must omit /register narrow (Zulip narrows are ANDed), which creates a broad event queue. monitor.ts now enforces channels.zulip.streams via a isMonitoredStream(...) check for inbound stream messages.
Numeric stream_id reply targets: when display_recipient is absent we now resolve the stream name via /streams/{id} (cached) so outbound replies prefer stream:<name>: rather than falling back to the numeric id.

Includes a small unit test for isMonitoredStream.

(Commit: 0338bdf)

simpliq-marvin · 2026-02-11T18:12:23Z

@greptileai could you re-review? We addressed the two concerns you raised:

enforce monitored-stream filtering when registering a broad event queue (multi-stream case)
resolve missing stream names via /streams/{id} (cached) so replies don't fall back to numeric stream_id

Latest commit: 0338bdf

greptile-apps

_{30 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-11T18:25:58Z

extensions/zulip/src/zulip/send.ts

+  if (lower.startsWith("stream:")) {
+    const rest = trimmed.slice("stream:".length).trim();
+    if (!rest) {
+      throw new Error("Stream name is required for Zulip sends");
+    }
+    const [stream, topic] = rest.split(/[:#/]/);
+    return { kind: "stream", stream: stream.trim(), topic: topic?.trim() };
+  }


Topic parsing truncates

parseZulipTarget() splits stream:NAME[:topic] using rest.split(/[:#/]/) and destructures [stream, topic], so any topic containing : or # (and anything after the first separator) is silently dropped (e.g. stream:general:foo:bar becomes topic foo). This breaks the advertised :topic format for common topic strings and can route messages to the wrong topic.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/zulip/src/zulip/send.ts Line: 71:78 Comment: **Topic parsing truncates** `parseZulipTarget()` splits `stream:NAME[:topic]` using `rest.split(/[:#/]/)` and destructures `[stream, topic]`, so any topic containing `:` or `#` (and anything after the first separator) is silently dropped (e.g. `stream:general:foo:bar` becomes topic `foo`). This breaks the advertised `:topic` format for common topic strings and can route messages to the wrong topic. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-11T18:25:59Z

extensions/zulip/src/zulip/monitor.ts

+    const mentionRegexes = core.channel.mentions.buildMentionRegexes(cfg, "main");
+    const wasMentioned =
+      !isDM &&
+      (rawText.toLowerCase().includes(`@${botUsername.toLowerCase()}`) ||
+        core.channel.mentions.matchesMentionPatterns(rawText, mentionRegexes));


Hardcoded agentId for mentions

Mention detection is built with buildMentionRegexes(cfg, "main") before resolveAgentRoute() runs, but mention patterns are agent-scoped (derived from the routed agent’s identity / groupChat.mentionPatterns). If routing selects a non-main agent and requireMention is enabled, messages that correctly mention that agent can be treated as “not mentioned” and dropped.

Prompt To Fix With AI

This is a comment left during a code review. Path: extensions/zulip/src/zulip/monitor.ts Line: 379:383 Comment: **Hardcoded agentId for mentions** Mention detection is built with `buildMentionRegexes(cfg, "main")` before `resolveAgentRoute()` runs, but mention patterns are agent-scoped (derived from the routed agent’s identity / `groupChat.mentionPatterns`). If routing selects a non-`main` agent and `requireMention` is enabled, messages that correctly mention that agent can be treated as “not mentioned” and dropped. How can I resolve this? If you propose a fix, please make it concise.

Adds a full-featured Zulip channel plugin with: Core Features: - Event queue polling with exponential backoff and auto-recovery - Authenticated upload downloads from /user_uploads/ - Outbound file uploads via /api/v1/user_uploads - Reaction indicators (eyes → check_mark/warning) - Topic directive [[zulip_topic: <topic>]] - HTTP retry with backoff (429/502/503/504) - Full actions API (stream CRUD, user management, reactions) - Channel docs and unit tests Key Improvement Over Existing PRs: - Implements CONCURRENT message processing with staggered start times - Other PRs (openclaw#9643, openclaw#14182) process messages sequentially, causing reply delays and "message dumps" when multiple messages arrive - This implementation starts processing each message immediately with a 200ms stagger for natural conversation flow - Replies arrive as each finishes instead of all at once Technical Details: - Fire-and-forget message processing with per-message error handling - Maintains event cursor and queue ID correctly during concurrent processing - Tested live and confirmed significant UX improvement Refs: openclaw#5163, openclaw#8365, openclaw#9643, openclaw#12183

openclaw-barnacle · 2026-02-21T04:09:35Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Adds a full-featured Zulip channel plugin with: Core Features: - Event queue polling with exponential backoff and auto-recovery - Authenticated upload downloads from /user_uploads/ - Outbound file uploads via /api/v1/user_uploads - Reaction indicators (eyes → check_mark/warning) - Topic directive [[zulip_topic: <topic>]] - HTTP retry with backoff (429/502/503/504) - Full actions API (stream CRUD, user management, reactions) - Channel docs and unit tests Key Improvement Over Existing PRs: - Implements CONCURRENT message processing with staggered start times - Other PRs (openclaw#9643, openclaw#14182) process messages sequentially, causing reply delays and "message dumps" when multiple messages arrive - This implementation starts processing each message immediately with a 200ms stagger for natural conversation flow - Replies arrive as each finishes instead of all at once Technical Details: - Fire-and-forget message processing with per-message error handling - Maintains event cursor and queue ID correctly during concurrent processing - Tested live and confirmed significant UX improvement Refs: openclaw#5163, openclaw#8365, openclaw#9643, openclaw#12183

openclaw-barnacle · 2026-03-12T04:11:31Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-03-15T04:17:03Z

Closing due to inactivity.
If you believe this PR should be revived, post in #pr-thunderdome-dangerzone on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

FtlC-ian and others added 10 commits February 8, 2026 17:48

fix: coerce event ID to number in poll loop

4e52c40

Addresses Greptile review feedback: ensure lastEventId stays as a number type when assigned from event response data.

chore: update pnpm-lock.yaml for zulip extension

6a84bf3

style: format zulip extension with oxfmt

d4db981

fix(zulip): bound handler concurrency, pin uploads, add url aliases

5ef83cd

zulip: harden event handling + safe upload auth

6b58817

zulip: self-heal on bad event queue id

9b4adeb

zulip: log queue re-registration

958729e

zulip: fix alias precedence and remove temp inbound logs

8812948

openclaw-barnacle bot added the docs Improvements or additions to documentation label Feb 11, 2026

greptile-apps bot reviewed Feb 11, 2026

View reviewed changes

FtlC-ian mentioned this pull request Feb 12, 2026

feat: Zulip channel plugin with concurrent message processing #15051

Closed

jamie-dit mentioned this pull request Feb 14, 2026

feat: add Zulip channel plugin #15887

Closed

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

openclaw-barnacle bot added stale Marked as stale due to inactivity and removed stale Marked as stale due to inactivity labels Feb 21, 2026

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 12, 2026

openclaw-barnacle bot closed this Mar 15, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

zulip: fix event queue registration for multiple monitored streams#14182

zulip: fix event queue registration for multiple monitored streams#14182
simpliq-marvin wants to merge 11 commits intoopenclaw:mainfrom
simpliq-marvin:marvin/harden-12183-on-feat

simpliq-marvin commented Feb 11, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 11, 2026

Uh oh!

greptile-apps bot Feb 11, 2026

Uh oh!

simpliq-marvin commented Feb 11, 2026

Uh oh!

simpliq-marvin commented Feb 11, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 11, 2026

Uh oh!

greptile-apps bot Feb 11, 2026

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

openclaw-barnacle bot commented Mar 12, 2026

Uh oh!

openclaw-barnacle bot commented Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

simpliq-marvin commented Feb 11, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Tests

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

simpliq-marvin commented Feb 11, 2026

Uh oh!

simpliq-marvin commented Feb 11, 2026

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

openclaw-barnacle bot commented Feb 21, 2026

Uh oh!

openclaw-barnacle bot commented Mar 12, 2026

Uh oh!

openclaw-barnacle bot commented Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

simpliq-marvin commented Feb 11, 2026 •

edited by greptile-apps bot

Loading