How to recognize a re-commit (of a transaction from CLI) in hook code?

kindly asking for help as I couldn’t figure it out for myself based on ConfD User’s Guide. I’m using

I have a hook (actually multiple hooks) in place in order to supplement user’s commit with additional configuration.

Some of the hooks may fail. In that case I’m setting an informative error message with confd_trans_seterr_extended and I get corresponding “Aborted:” message in CLI.

Unfortutely my hooks are stateful: I need to maintain state from one callback to another… I reset that state in init callback.

But in case of CLI if user does ‘commit’ again there’s no new init callback and the hooks are replayed…

So I desperately need to know if:
1/ is there a working method to distinguish between subsequent ‘commit’ request from user in order to reset state of my hooks? Is it another callback I can use? But In that case will all of my hook callbacks be replayed as on first commit (+/- any changes user made in between)?
or 2/ can I abort the transaction completely from hook code in order to get that new init callback?
and 3/ Is CLI different than NETCONF in this respect?

Thank you in advance for help!
Best regards,

Hey Filip,
You are triggering a few red flags with your comments.

  1. Transaction hooks are not to be used for validation. You don’t want them to fail. You should use a validation point in the validation phase for that, or if you actually need to test to set something, you should use a subscriber in the prepare phase.
  2. Transaction hooks and validation points should not be stateful. You will create issues with loading backups and doing rollbacks. See ConfD UG 11.5. Validation Logic.
  3. If the goal is to reduce the number of subscriber applications, this is not the way to do it. Instead, merge the subscriber applications to for example share the subscriber mechanism.

Best regards

Thank you Conny, I appreciate your comments, I shall rethink my design again with respect to your points. By the way:

ad 3. While I work on that point too (reducing number of subscriptions) that’s is not what I want to accomplish by hooks. It’s just that there’s some additional configuration to be done with user’s. That’s some internal configuration that user should not be bothered with. Idealy I would like to either commit one consistent configuration (user’s + my addendum) or neither.

ad 1. I get it. Until now we used to supplement this configuration in subscriptions (at that Commit box on the diagram) but at the same time CDB subscribers can’t abort user’s transaction, right?

So you suggest I should go with subscriptions in the prepare phase?

Thanks for the additional input Filip,
So to add configuration, the rule is that it is ok to do so if:

  • The config is not visible or writable to the manager, i.e no out of band configuration that makes manager out of sync with the config)

  • And if you add such config, you want to do that in a transaction hook so that the added config go through the validation together with the original config. I.e. you just add new config to the transaction, not setting it in the system (that is done in the commit or in some cases the prepare phase)

In the commit phase no, in the prepare phase before the “point of no return”, yes.

It seems like that. If you just add some private config to the transaction itself, you can do that in a transaction hook.
But if, and that’s what it seems like, if you need to set some things in your system (not only in the transaction), you do that in the prepare phase as a prepare phase CDB subscriber. And in that phase, you can abort the transaction properly.