Daniel-Constantin Mierla writes:
As I wrote on the mailing list, flags should not be migrated to the transaction after t_newtran() unless one uses t_flush_flags() -- that was the desired functionality, otherwise t_flush_flags() has no purpose.
I have used flags for many years and for me it has been desirable that they are available after t_newtrans() in failure and onreply routes without a need to call t_flush_flags(). If someone wants to change that behavior and make t_flush_flags() purposeful, then a tm variable can be introduced to achieve that new behavior.
You opened another item on this tracker related to this unexpected behaviour (#1490), and I think it is better to sort this out there, because that is the unexpected behaviour. xflags behave as expected. Whatever will be the conclusion of #1490 will be applied to both flags and xflags, but makes no sense to track an issue with two separate items.
I opened this issue, because I needed more that 32 flags, i.e., flags that work the same way as before, but more of them. It is OK to replace flags with xflags if my current configuration file keeps on working when I textually change current flag function calls with xflag function calls, but it is not OK if I need to start adding t_flush_xflags() calls to it.
Issue "Is t_flush_flags() really needed? #1490" asks about the purpose of t_flush_flags() function. I have not been able to figure out one, but perhaps there is some. If there is no purpose, then the function should be removed.
-- Juha