Hi Jean-Daniel,
thank you much for reporting this issue. It is certainly a bug which
came as a regression while implementing more complex enhancement.
We will fix it for the next releases.
Libor
On 07. 01. 25 19:32, Jean-Daniel Dupas wrote:
My bad, I mixed up version of my components, the
production version that is working fine is 3.3.5, not 3.4.0 (as I thought initially), so
yes, it should behave the same since 3.4.0.
Le 7 janv. 2025 à 19:15, David Vasek
<david.vasek(a)nic.cz> a écrit :
Hello Jeans/Daniel,
thank you for reporting it. Obviously, hanging until timeout isn't intended here.
When you write "since 3.4.1" and "until 3.4.1" - do you mean that it
worked same as before in 3.4.0, or did you skip that version? We believe it should be the
same in 3.4.0 as it is in 3.4.1.
Regards,
David
On 2025-01-07 17:47, Jean-Daniel Dupas wrote:
> Hello,
> I have an issue with a behaviour change in knot 3.4.1.
> Before 3.4.1, trying to send a conf-abort command using knotc to knot when there was
no pending transaction properly returned an error, but since 3.4.1, instead of receiving
an error, the connection hangs, and failed after a timeout.
> Some digging shows that this is due to a change in commit
69328dd7799253978605f7dac29175945971e63f
> Instead of returning and error as it should, ctl_process skip the command processing
when it does not expect a conf-abort command.
> Is this a bug, or is this behaviour intended ?
> Just to give you some context about my use case, I wrote a daemon that is using
libknot to sync the dns configuration, and as knot does not supports multiple transaction,
it has to make sure there is no dangling transaction before trying to apply changes (in
case the daemon did crash while applying a previous change). Until 3.4.1, it did that by
simply sending a conf-abort before starting the new transaction.
> Thanks
> --
--