Abort callback order

[EvgeniiVR]

Hello team,

Is there any way to make clixon backend to run abort callback before revert?

Let me describe my concern in more details, we have 4 plugins, e.g.
PLUGIN 1
PLUGIN 2
PLUGIN 3
PLUGIN 4
that run in the appropriate order.
Let's say PLUGIN 4's commit callback fails with error:

May 11 18:55:08.160357: [PLUGIN 1] plugin1_begin: BEGIN DONE.
May 11 18:55:08.160380: [PLUGIN 2] plugin2_begin: BEGIN DONE.
May 11 18:55:08.160391: [PLUGIN 3] plugin3_begin: BEGIN DONE.
May 11 18:55:08.160397: [PLUGIN 4] plugin4_begin: BEGIN DONE.
May 11 18:55:08.160402: [PLUGIN 1] plugin1_validate: VALIDATE DONE.
May 11 18:55:08.160409: [PLUGIN 2] plugin2_validate: VALIDATE DONE.
May 11 18:55:08.160412: [PLUGIN 3] plugin3_validate: VALIDATE DONE.
May 11 18:55:08.160417: [PLUGIN 4] plugin4_validate: VALIDATE DONE.
May 11 18:55:08.160434: [PLUGIN 1] plugin1_complete: COMPLETE DONE.
May 11 18:55:08.160442: [PLUGIN 2] plugin2_complete: COMPLETE DONE.
May 11 18:55:08.160445: [PLUGIN 3] plugin3_complete: COMPLETE DONE.
May 11 18:55:08.160448: [PLUGIN 4] plugin4_complete: COMPLETE DONE.
May 11 18:55:08.160459: [PLUGIN 1] plugin1_commit: COMMIT DONE.
May 11 18:55:08.160468: [PLUGIN 2] plugin2_commit: COMMIT DONE.
May 11 18:55:08.160471: [PLUGIN 3] plugin3_commit: COMMIT DONE.
May 11 18:55:08.160474: [PLUGIN 4] plugin4_commit: COMMIT FAILED.

Then backend starts in reverse order revert callbacks and then abort callbacks:

May 11 18:55:08.160484: [PLUGIN 3] plugin3_revert: REVERT DONE.
May 11 18:55:08.160487: [PLUGIN 2] plugin2_revert: REVERT DONE.
May 11 18:55:08.160490: [PLUGIN 1] plugin1_revert: REVERT DONE.
May 11 18:55:08.160494: [PLUGIN 1] plugin1_abort: ABORT DONE.
May 11 18:55:08.160497: [PLUGIN 2] plugin2_abort: ABORT DONE.
May 11 18:55:08.160500: [PLUGIN 3] plugin3_abort: ABORT DONE.
May 11 18:55:08.160503: [PLUGIN 4] plugin4_abort: ABORT DONE.

Revert callbacks run only for "successfully commited" plugins starting from PLUGIN 3->2->1.
But in case PLUGIN 4 managed to leave any "print" on the system before it failed and from data/yang model prospective has references on previous plugins then we have to make some operations to clear that "print" before revert operations for PLUGIN 3->2->1 ,
but we don't have any place holder for that.

[olofhagsand]

Yes, I am aware of that glitch, but was unsure of what to do in the case of a transaction failing in the middle of a single (of many) commit plugins.
I am open to suggestion on how to address this, as long as it is backward compatible.
Are you saying you would rather switch the plugin calls, so that abort is called before revert, and that would solve your problem? This could be done by adding an option.
Another way would be to add (yet another) callback, called at the time of the first commit error.

[EvgeniiVR]

Hello @olofhagsand,
Was looking on abort callback as it is the only callback that run for the plugin after failed commit callback.
But if it is possible to introduce special callback type that run once before the revert callback phase and only for the failed plugin - I believe it is the best way to resolve this glitch. Then there'll be a placeholder for the code to incrementally rollback "print" within the failed plugin.

[olofhagsand]

OK, lets add a new callback.
It should be straightforward, just follow the code of the other transaction callbacks, in case you want to make a PR?

[EvgeniiVR]

yep, would like to follow with the PR. Do I need to create separate issue for the PR?

[olofhagsand]

Yes, maybe you could add a separate issue to describe what to add and then reference that from a PR.
Then I can close this discussion.

[EvgeniiVR]

@olofhagsand I've created new PR w/ reference on this discussion
#518
Thank you!