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.va...@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 >> -- --
