Some messages not buffered if client disconnects without /quit and then times out #215

New Issue

2026-10-05T04:05:16+02:00

adam commented

2026-10-05 04:05:16 +02:00

If I disconnect from znc due to an issue with my internet connection, some buffer may be lost, leading to confused conversations as someone assumes you saw their reply.

It would be nice to have an option to make znc keep a buffer of what was said between now and the last successful ping, and add that to the buffer if the client disconnects due to missing a ping, or E_CONN_RESET/other similar error.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/244531-some-messages-not-buffered-if-client-disconnects-without-quit-and-then-times-out?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).

If I disconnect from znc due to an issue with my internet connection, some buffer may be lost, leading to confused conversations as someone assumes you saw their reply. It would be nice to have an option to make znc keep a buffer of what was said between now and the last successful ping, and add that to the buffer if the client disconnects due to missing a ping, or E_CONN_RESET/other similar error. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/244531-some-messages-not-buffered-if-client-disconnects-without-quit-and-then-times-out?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:05:17 +02:00

This is why i use awaystore plugin for private messages and auto clear buffer is off.

This is why i use awaystore plugin for private messages and auto clear buffer is off.

adam commented

2026-10-05 04:05:17 +02:00

+1 for this idea. Ping timeouts are still a problem on most servers. Having a feature that saves buffer messages if a ping was not successful, is very welcome.

+1 for this idea. Ping timeouts are still a problem on most servers. Having a feature that saves buffer messages if a ping was not successful, is very welcome.

adam commented

2026-10-05 04:05:18 +02:00

I observe this problem in my own setup, and am concerned that it happens. It suggests that there is a code path through which a message can show up and, failing delivery to the user, be dropped on the floor. TCP socket calls will provide sufficient information to detect delivery error, so it concerns me that this is a problem at all.

I observe this problem in my own setup, and am concerned that it happens. It suggests that there is a code path through which a message can show up and, failing delivery to the user, be dropped on the floor. TCP socket calls will provide sufficient information to detect delivery error, so it concerns me that this is a problem at all.

adam commented

2026-10-05 04:05:19 +02:00

Since I'm using standby to "power off" the PC, I also have the issue of mIRC not telling ZNC it is quitting. What concerns me the most is that I actually missed a query and only learned of it much later. After looking into it a bit, it seems like I was missing chat history of at least 5min after putting the PC into standby.

Since I'm using standby to "power off" the PC, I also have the issue of mIRC not telling ZNC it is quitting. What concerns me the most is that I actually missed a query and only learned of it much later. After looking into it a bit, it seems like I was missing chat history of at least 5min after putting the PC into standby.

adam commented

2026-10-05 04:05:19 +02:00

There is this pull request https://github.com/znc/znc/pull/598 which attempts to fix this.

There is this pull request https://github.com/znc/znc/pull/598 which attempts to fix this.

adam commented

2026-10-05 04:05:20 +02:00

@Mkaysi That would not fix channels losing messages since it does not touch the channel logic.

@Mkaysi That would not fix channels losing messages since it does not touch the channel logic.

adam commented

2026-10-05 04:05:21 +02:00

Oh sorry, I thought that message = private message.

Oh sorry, I thought that message = private message.

adam commented

2026-10-05 04:05:21 +02:00

Mhh, not sure if this would fix the query side.
ZNC seems to behave like the client is still connected after a silent connection loss (which is of course normal),
but then not noticing it was unable to deliver the messages to the client and therefore being lost.

I'll do some testing later and see if I can consistently reproduce it.

Mhh, not sure if this would fix the query side. ZNC seems to behave like the client is still connected after a silent connection loss (which is of course normal), but then not noticing it was unable to deliver the messages to the client and therefore being lost. I'll do some testing later and see if I can consistently reproduce it.

adam commented

2026-10-05 04:05:22 +02:00

I regularly observe this problem on an IRC/ZNC server that is oftenly accessed via VPN from countries where internet is not so reliable.
When someone's connection is lost for some reason, messages sent in the following ~20s doesn't appear in his backlog when he reconnects.

I regularly observe this problem on an IRC/ZNC server that is oftenly accessed via VPN from countries where internet is not so reliable. When someone's connection is lost for some reason, messages sent in the following ~20s doesn't appear in his backlog when he reconnects.

adam commented

2026-10-05 04:05:23 +02:00

Has any headway been made in relation to this issue?

Has any headway been made in relation to this issue?

adam commented

2026-10-05 04:05:23 +02:00

This is the solution that I've been happily using for a year: http://wiki.znc.in/Playback. Yes, it needs special support from your client, but that's not difficult to implement.

This is the solution that I've been happily using for a year: http://wiki.znc.in/Playback. Yes, it needs special support from your client, but that's not difficult to implement.

adam commented

2026-10-05 04:05:24 +02:00

Yes, it needs special support from your client, but that's not difficult to implement.

Is this currently supported by anything else than Communi-*?

> Yes, it needs special support from your client, but that's not difficult to implement. Is this currently supported by anything else than Communi-*?

adam commented

2026-10-05 04:05:25 +02:00

Is this currently supported by anything else than Communi-*?

Textual & Mobile Colloquy

> Is this currently supported by anything else than Communi-*? Textual & Mobile Colloquy

adam commented

2026-10-05 04:05:25 +02:00

The OP's proposed solution would be a very welcomed feature.

The OP's proposed solution would be a very welcomed feature.

adam commented

2026-10-05 04:05:26 +02:00

Assuming I'm not missing any important technical detail that would lead to issues, I agree with @caktux, as this solution would (hopefully) work with all standard clients and not require special plugins.

Assuming I'm not missing any important technical detail that would lead to issues, I agree with @caktux, as this solution would (hopefully) work with all standard clients and not require special plugins.

adam commented

2026-10-05 04:05:27 +02:00

Could this be closed based on *playbck or will this wait for it to be merged to ZNC?

Could this be closed based on *playbck or will this wait for it to be merged to ZNC?

adam commented

2026-10-05 04:05:27 +02:00

I'm not entirely sure if a solution to this issue should require non-standard client implementations and/or (third-party) plugins.

I'm not entirely sure if a solution to this issue should require non-standard client implementations and/or (third-party) plugins.

adam commented

2026-10-05 04:05:28 +02:00

Isn't this what the clearbufferonmsg module is for?

Isn't this what the `clearbufferonmsg` module is for?

adam commented

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

It never checks whether the actual `write(...)' call succeeded :(
I'll see if I can come up w/ sthing!

It never checks whether the actual `write(...)' call succeeded :( I'll see if I can come up w/ sthing!

adam commented

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

o/ o/

So, I think the issue is fixed by the commit I made in my fork (Idk if it shows here for others.)

However, only when using the clientbuffer module. I could carry on looking for fixing w/o, but that wouldn't be solving a problem I have.

I'll send a PR for now with that, at least it is something.

o/ o/ So, I **think** the issue is fixed by the commit I made in my fork (Idk if it shows here for others.) However, only when using the `clientbuffer` module. I **could** carry on looking for fixing w/o, but that wouldn't be solving a problem I have. I'll send a PR for now with that, at least it is something.

adam commented

2026-10-05 04:05:30 +02:00

Isn't this what the clearbufferonmsg module is for?

So I guess yes, it is, after educating myself.
(At first I thought write() or SSL_write() returning <= 0 meant that the message did not make it, and therefore the other way around meant that it did however as it turns out SSL_write() may still return a # of byte transmitted even though the connection is down, and for good.)

I think we could improve ZNC to only clear the buffer upon receiving a pong, and we could emit a ping along with each messages. But, yeah, this is virtually the same as using clearbufferonmsg (ty @AndrioCelos )

Since I am using the clientbuffer module I will take my suggestion there.

> Isn't this what the `clearbufferonmsg` module is for? So I guess yes, it is, after educating myself. (At first I thought `write()` or `SSL_write()` returning <= 0 meant that the message did not make it, and therefore the other way around meant that it did however as it turns out `SSL_write()` may still return a # of byte transmitted even though the connection is down, and for good.) I think we could improve ZNC to only clear the buffer upon receiving a pong, and we could emit a ping along with each messages. But, yeah, this is virtually the same as using `clearbufferonmsg` (ty @AndrioCelos ) Since I am using the `clientbuffer` module I will take my suggestion there.

adam commented

2026-10-05 04:05:31 +02:00

I observe this problem in my own setup, and am concerned that it happens. It suggests that there is a code path through which a message can show up and, failing delivery to the user, be dropped on the floor. TCP socket calls will provide sufficient information to detect delivery error, so it concerns me that this is a problem at all.

I was exactly same but as it turns out TCP being reliable merely means that when the connection cuts, you will now eventually about it, however not exactly at the moment it happens.

So the proper fix sounds like being folding the module clearbufferonmessage in ZNC.

Considering the wiki for it says that it addresses this very issue, a point can be made this is simply how the software is designed.

As per my previous comment an issue remains with znc-clientbuffer. I'll open it up there

> I observe this problem in my own setup, and am concerned that it happens. It suggests that there is a code path through which a message can show up and, failing delivery to the user, be dropped on the floor. TCP socket calls will provide sufficient information to detect delivery error, so it concerns me that this is a problem at all. I was exactly same but as it turns out TCP being reliable merely means that when the connection cuts, you **will now eventually** about it, however not exactly at the moment it happens. So the proper fix sounds like being folding the module `clearbufferonmessage` in ZNC. Considering the wiki for it says that it addresses this very issue, a point can be made this is simply how the software is designed. As per my previous comment an issue remains with znc-clientbuffer. I'll open it up there

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#215