You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
Looking at the plugin code I realized that there is a single subscription to the entire module (e.g., "/interface"), and changes are made to the network stack through libnl during the validation phase (event type being SR_EV_CHANGE). Additionally, since the plugin uses a single callback for the entire module, the SR_EV_ABORT event, as described in the sysrepo documentation, will not be generated specifically for this single callback:
"This event is also generated for RPC subscriptions when a later callback has failed and this one has already successfully processed SR_EV_RPC. The callback that failed will never get this event!"
My concern is related to a scenario with a transaction that involves multiple modifications. In such cases, if one of these modifications fails (for example, due to an error returned by libnl), it can cause the callback handling the changes to fail as well. This raises a concern about how the system is reverted to its state before the commit, effectively undoing the modifications that were already processed. In my limited understanding of the code, if a failure occurs, the modifications are not properly undone and the system does not return to the state before the commit. Is this correct?
The text was updated successfully, but these errors were encountered:
Hi,
Looking at the plugin code I realized that there is a single subscription to the entire module (e.g., "/interface"), and changes are made to the network stack through libnl during the validation phase (event type being SR_EV_CHANGE). Additionally, since the plugin uses a single callback for the entire module, the SR_EV_ABORT event, as described in the sysrepo documentation, will not be generated specifically for this single callback:
https://netopeer.liberouter.org/doc/sysrepo/master/html/group__change__subs__api.html#gad007e862874bda7141c58ca72d8c1067
My concern is related to a scenario with a transaction that involves multiple modifications. In such cases, if one of these modifications fails (for example, due to an error returned by libnl), it can cause the callback handling the changes to fail as well. This raises a concern about how the system is reverted to its state before the commit, effectively undoing the modifications that were already processed. In my limited understanding of the code, if a failure occurs, the modifications are not properly undone and the system does not return to the state before the commit. Is this correct?
The text was updated successfully, but these errors were encountered: