A typical CDB subscriber is only interested in knowing when the configuration is changed and handling those changes. The subscriber is notified during the commit phase, and at this point if the subscriber detects some condition that prevents the underlying platform software from accepting the configuration change, then all that can be done is to raise some sort of error, since the configuration transaction is past the point of no return.
In order to support situations where the subscriber needs to perform some sort of check, the CDB APIs support a two-phase subscription, where the subscriber is notified during the prepare phase as well as the commit phase. During the prepare phase, the subscriber can perform any checking it needs to, such as checking for adequate resources or that hardware dependencies can be met.
In order to establish a two-phase subscription, you use the cdb_subscribe2() API call rather than the cdb_subscribe() API call. Once the subscription is triggered, you use the cdb_read_subscription_socket2() to determine which phase of the transaction you are in.
There is a worked out example of using two-phase subscriptions in $CONFD_DIR/examples.confd/cdb_subscription/twophase