route_replies doesn't route monitor #555

New Issue

2026-10-05T04:29:38+02:00

adam commented

2026-10-05 04:29:38 +02:00

I usually have two clients in ZNC, WeeChat and Communi Sailfish. WeeChat always puts some users to monitor, but Communi Sailfish gets them too.

The numerics I see are 731 (offline) and 730 (online).

ZNC 1.7.x-git-250-645fa85 - http://znc.in
- IPv6: yes, SSL: yes, DNS: threads, charset: yes
Debian GNU/Linux 7.8 (wheezy)

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25906731-route_replies-doesn-t-route-monitor?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

- Moved from https://github.com/communi/communi-sailfish/issues/106 - http://ircv3.net/specs/core/monitor-3.2.html I usually have two clients in ZNC, WeeChat and Communi Sailfish. WeeChat always puts some users to monitor, but Communi Sailfish gets them too. The numerics I see are 731 (offline) and 730 (online). --- - ZNC 1.7.x-git-250-645fa85 - http://znc.in - IPv6: yes, SSL: yes, DNS: threads, charset: yes - Debian GNU/Linux 7.8 (wheezy) ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/25906731-route_replies-doesn-t-route-monitor?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:29:39 +02:00

Adding the replies to the list in route_replies is not as simple as it looks at first.

As http://ircv3.net/specs/core/monitor-3.2.html describes, MONITOR S:

Outputs for each target in the list being monitored, whether the client is online or offline. All targets that are online will be sent using RPL_MONONLINE, all targets that are offline will be sent using RPL_MONOFFLINE.

So you may get either RPL_ONLINE, RPL_OFFLINE, or both replies. The module wants to know which one is the last response, which is, as far as I can tell, impossible to specify at compile time.

A) all monitored targets are online => RPL_ONLINE only
B) all monitored targets are offline => RPL_OFFLINE only
C) some monitored targets are online, some offline => RPL_ONLINE and RPL_OFFLINE

No matter what combination is specified for route_replies, either a response leaks through, or the module hits a timeout in one of the above cases.

Adding the replies to the list in route_replies is not as simple as it looks at first. As http://ircv3.net/specs/core/monitor-3.2.html describes, `MONITOR S`: > Outputs for each target in the list being monitored, whether the client is online or offline. All targets that are online will be sent using RPL_MONONLINE, all targets that are offline will be sent using RPL_MONOFFLINE. So you may get either `RPL_ONLINE`, `RPL_OFFLINE`, or both replies. The module wants to know which one is the last response, which is, as far as I can tell, impossible to specify at compile time. A) all monitored targets are online => `RPL_ONLINE` only B) all monitored targets are offline => `RPL_OFFLINE` only C) some monitored targets are online, some offline => `RPL_ONLINE` _and_ `RPL_OFFLINE` No matter what combination is specified for route_replies, either a response leaks through, or the module hits a timeout in one of the above cases.

adam commented

2026-10-05 04:29:39 +02:00

I think this is a lot more complicated for a couple of reasons:

A route replies module for MONITOR would need to track which monitor subscription each client has made and route any monitor numerics to the correct client. There is an immediate RPL_ONLINE/RPL_OFFLINE but, at any time the monitored nick becomes online/offline there will be a following message that would need to be routed to the correct client(s).
This is also problematic as any clients attempting to track the monitored subscription count would produce incorrect amount of subscriptions if some subscriptions are hidden from the client. A server may advertise a limit to the MONITOR subscriptions in 005 (ISUPPORT) which the client may be tracking the amount of subscriptions so it doesn't hit the servers limit. However if the client is not aware of all subscriptions then the amount of subscriptions would be incorrect.

I think for these reasons it perhaps makes sense that all clients are forwarded the monitor subscription information.

I think this is a lot more complicated for a couple of reasons: - A route replies module for MONITOR would need to track which monitor subscription each client has made and route any monitor numerics to the correct client. There is an immediate RPL_ONLINE/RPL_OFFLINE but, at any time the monitored nick becomes online/offline there will be a following message that would need to be routed to the correct client(s). - This is also problematic as any clients attempting to track the monitored subscription count would produce incorrect amount of subscriptions if some subscriptions are hidden from the client. A server may advertise a limit to the MONITOR subscriptions in 005 (ISUPPORT) which the client may be tracking the amount of subscriptions so it doesn't hit the servers limit. However if the client is not aware of all subscriptions then the amount of subscriptions would be incorrect. I think for these reasons it perhaps makes sense that all clients are forwarded the monitor subscription information.

adam commented

2026-10-05 04:29:40 +02:00

This does bring up a separate question though, if a client disconnects then ZNC is staying connected and thus persisting the monitor subscriptions. Perhaps these would need to be cleaned out once a client who subscribed disconnected.

This does bring up a separate question though, if a client disconnects then ZNC is staying connected and thus persisting the monitor subscriptions. Perhaps these would need to be cleaned out once a client who subscribed disconnected.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#555