Previously savebuff would correctly function on channels with AutoClearChanBuffer set, saving their buffers when the client is detached. This way the buffers could survive a reboot. In other words this worked:
Client detach
-> messages arrive on #foo
-> znc is restarted (vps goes down)
-> client reattaches
-> messages from #foo are replayed once
Previously savebuff would correctly function on channels with AutoClearChanBuffer set, saving their buffers when the client is detached. This way the buffers could survive a reboot. In other words this worked:
Client detach
-> messages arrive on #foo
-> znc is restarted (vps goes down)
-> client reattaches
-> messages from #foo are replayed _once_
I _believe_ it was facilitated by this check, currently present in the legacy section only: https://github.com/znc/znc/blob/master/modules/savebuff.cpp#L284
In version 1.xx we have this instead: https://github.com/znc/znc/blob/master/modules/savebuff.cpp#L169 - any channel with autoclear is never eligible for saving, and thus will not be replayed after a bouncer restart.
I consider this a nasty regression (the only way to get to such messages would be to trawl through the logs created by the log module manually).
Cheers
P. S. This issue is different from https://github.com/znc/znc/pull/108
##
<bountysource-plugin>
---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/567241-savebuff-does-not-work-across-restarts?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>
<!-- github-sync-id:16908391 -->
This is not a regression, that check was in place for years.
It needs to be fixed, but as 0.20x was broken in the same way, it may be done after 1.2
This is not a regression, that check was in place for years.
It needs to be fixed, but as 0.20x was broken in the same way, it may be done after 1.2
<!-- github-comment-id:22831198 -->
It may not be a regression in this particular piece of code, but it is a regression inasmuch I actually tested both versions by disconnecting, killing the corresponding znc process and all that jazz.
In other words while I do not claim my diagnosis is anywhere correct, I still stand behind the original bug-report being a new thing in 1.0
It may not be a regression in this particular piece of code, but it _is_ a regression inasmuch I actually tested both versions by disconnecting, killing the corresponding znc process and all that jazz.
In other words while I do not claim my diagnosis is anywhere correct, I still stand behind the original bug-report being a new thing in 1.0
<!-- github-comment-id:22863607 -->
I've tried 0.206, and it's exactly the same there...
I've set KeepBuffer to false, and savebuff module didn't save the buffer, though it should save it.
I've tried 0.206, and it's exactly the same there...
I've set KeepBuffer to false, and savebuff module didn't save the buffer, though it should save it.
<!-- github-comment-id:23516552 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Previously savebuff would correctly function on channels with AutoClearChanBuffer set, saving their buffers when the client is detached. This way the buffers could survive a reboot. In other words this worked:
Client detach
-> messages arrive on #foo
-> znc is restarted (vps goes down)
-> client reattaches
-> messages from #foo are replayed once
I believe it was facilitated by this check, currently present in the legacy section only: https://github.com/znc/znc/blob/master/modules/savebuff.cpp#L284
In version 1.xx we have this instead: https://github.com/znc/znc/blob/master/modules/savebuff.cpp#L169 - any channel with autoclear is never eligible for saving, and thus will not be replayed after a bouncer restart.
I consider this a nasty regression (the only way to get to such messages would be to trawl through the logs created by the log module manually).
Cheers
P. S. This issue is different from https://github.com/znc/znc/pull/108
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/567241-savebuff-does-not-work-across-restarts?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).This is not a regression, that check was in place for years.
It needs to be fixed, but as 0.20x was broken in the same way, it may be done after 1.2
It may not be a regression in this particular piece of code, but it is a regression inasmuch I actually tested both versions by disconnecting, killing the corresponding znc process and all that jazz.
In other words while I do not claim my diagnosis is anywhere correct, I still stand behind the original bug-report being a new thing in 1.0
I've tried 0.206, and it's exactly the same there...
I've set KeepBuffer to false, and savebuff module didn't save the buffer, though it should save it.
@ribasushi How did you test it with that version?
I'll try to prepare a test case later today (will get you the config in question)
I believe this won't happen with 1.6.0+ and can be closed.