ConfD User Community

Transaction does not copy from candidate to running

Writing to candidate db, but db is unchanged after successful completion. What am I missing or doing wrong?

Everything comes back CONFD_OK

TRACE MAAPI_WAIT_START 
 28-Jun-2022::16:32:33.337 4296/f7ac9010/3 SEND op=402 isrel=0 th=-1 2
 --> CONFD_OK
TRACE MAAPI_GET_RUNNING_DB_STATUS  28-Jun-2022::16:32:33.337 4296/f7ac9010/3 GOT 1
 --> CONFD_OK
TRACE MAAPI_START_USER_SESSION 
 28-Jun-2022::16:32:33.338 4296/f7ac9010/3 SEND op=100 isrel=0 th=-1 {#Bin<root>,{{127,0,0,1},0},system,1,false,[],{undefined,undefined,undefined,#Bin<../../../arm/s(25)....>}}
 --> CONFD_OK
TRACE MAAPI_START_TRANS 
 28-Jun-2022::16:32:33.339 4296/f7ac9010/3 SEND op=140 isrel=0 th=-1 {1,2,0,0,0,{undefined,undefined,undefined,#Bin<../../../arm/s(25)....>}}
 28-Jun-2022::16:32:33.343 4296/f7ac9010/3 GOT 145
 --> CONFD_OK
TRACE MAAPI_LOCK 
 28-Jun-2022::16:32:33.343 4296/f7ac9010/3 SEND op=120 isrel=0 th=-1 1
 --> CONFD_OK
TRACE MAAPI_SET_NAMESPACE 
 28-Jun-2022::16:32:33.344 4296/f7ac9010/3 SEND op=160 isrel=0 th=145 45417249
 --> CONFD_OK
TRACE MAAPI_DELETE ...
 28-Jun-2022::16:32:33.345 4296/f7ac9010/3 SEND op=174 isrel=0 th=145 ['ne',net,'dns',server']
 --> CONFD_OK
TRACE MAAPI_SET_VALUES ... <list of indexes and servers>

 --> CONFD_OK
TRACE MAAPI_VALIDATE_TRANS 
 28-Jun-2022::16:32:33.356 4296/f7ac9010/3 SEND op=144 isrel=0 th=145 {false,false}
 --> CONFD_OK
TRACE MAAPI_PREPARE_TRANS 
 28-Jun-2022::16:32:33.361 4296/f7ac9010/3 SEND op=145 isrel=0 th=145 0
 --> CONFD_OK
TRACE MAAPI_COMMIT_TRANS  --> CONFD_OK
TRACE MAAPI_STOP_TRANS  --> CONFD_OK
TRACE MAAPI_UNLOCK 
 28-Jun-2022::16:32:33.390 4296/f7ac9010/3 SEND op=121 isrel=0 th=-1 1
 --> CONFD_OK
TRACE MAAPI_CANDIDATE_COMMIT 
 28-Jun-2022::16:32:33.401 4296/f7ac9010/3 SEND op=125 isrel=0 th=-1 {undefined,#Bin<>,#Bin<>}
 --> CONFD_OK

I’m assuming you are invoking maapi_lock on the candidate database. In that case, you probably want to lock the datastore before starting the transaction and in particular unlock after you commit candidate to running. Doing it the other way round - as you do that - somewhat undermines the point of locking, there is a window when anyone can modify the datastore under your hands.

That said, I’m not sure why when you call maapi_unlock on modified candidate it synchronizes candidate with running; and neither if it is intentional or it is a bug.