#RPC revert-changes
This RPC is used to revert previously configured changes. To revert one or more transactions, their transaction ids must be included in the body of the RPC. The transaction id is part of transaction metadata created by the transaction tracker after the commit/checked-commit RPC.
This RPC only updates data in the CONFIGURATION
snapshot. To write reverted data to the device, use RPC commit after RPC revert-changes.

#Ignore non-existing nodes
When reverting multiple transactions, some transaction metadata may contain nodes that do not currently exist in UniConfig. In this case, the RPC fails.
There are two options for handling non-existing nodes:
- Remove transactions that contain non-existing nodes from the request body.
- Add the
ignore-non-existing-nodes
parameter to the RPC request body with a value oftrue
(the default value isfalse
).
If the ignore-non-existing-nodes
parameter is not specified, the default value is used.
#RPC examples
#Successful examples
To revert a transaction, we need to find its ID. Let's use a GET
request to display all stored transaction metadata.
Revert changes for a single transaction.
Revert changes for multiple transactions.
Revert changes for multiple transactions. The transaction with id 2c4c1eb5-185a-4204-8021-2ea05ba2c2c1
contains the non-existing node R1
. Since the ignore-non-existing-nodes
parameter is set to true
, the RPC is successful.
#Failed example
The request contains a non-existing transaction in the request body.
Reverting changes for multiple transactions. The transaction metadata with id 2c4c1eb5-185a-4204-8021-2ea05ba2c2c1
contains a non-existing node. Since the ignore-non-existing-nodes
parameter is set to false
, the RPC fails.