# Cdb\_trigger\_subscriptions() returns CONFD\_OK in failure case

**URL:** <https://dmap-community.ductus.global/t/cdb-trigger-subscriptions-returns-confd-ok-in-failure-case/4039>\
**Category:** CDB and CDB API\
**Created:** [March 31, 2022, 8:51am UTC](https://dmap-community.ductus.global/t/cdb-trigger-subscriptions-returns-confd-ok-in-failure-case/4039 "2022-03-31T08:51:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![tatyakadam](https://avatars.discourse-cdn.com/v4/letter/t/8e8cbc/32.png) [@tatyakadam](https://dmap-community.ductus.global/u/tatyakadam)\
**Post date:** [March 31, 2022, 8:51am UTC](https://dmap-community.ductus.global/t/cdb-trigger-subscriptions-returns-confd-ok-in-failure-case/4039/1 "2022-03-31T08:51:05Z")

</div>

cdb\_trigger\_subscriptions() is a blocking call & it does return with CONF\_OK once all subscribers have acknowledged the notification.

In my case, while cdb\_trigger\_subscriptions() is in progress because of some reason confd closes the socket and my system does confd resync.

So once confd socket closed, cdb\_trigger\_subscriptions() gets unblocked with return value as CONFD\_OK. Here I am expecting cdb\_trigger\_subscriptions() should get unblocked with CONFD\_ERR as it got unblocked in-between i.e. without completion of subscribers notification.

Is there any way to detect this failure?  
I tried to use confd\_trans\_seterr\_extended() but it need transaction context which is not available for cdb\_trigger\_sunscriptions().

---

<div class="post-metadata">

**Author:** ![mvf](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/mvf/32/182_2.png) [@mvf](https://dmap-community.ductus.global/u/mvf)\
**Post date:** [April 1, 2022, 3:15pm UTC](https://dmap-community.ductus.global/t/cdb-trigger-subscriptions-returns-confd-ok-in-failure-case/4039/2 "2022-04-01T15:15:52Z")

</div>

CDB subscribers are never declared like callbacks that implement action callbacks or data provider callbacks, so ConfD is happy to keep running with or without them. Things are a bit different with “mandatory subscribers”, but that does not apply to `cdb_trigger_subscriptions` either.

So, I’m afraid you are on your own here. `cdb_trigger_subscriptions` is typically called from a watchdog application that takes care of (re)starting applications. If that is your case, you already have a solution at hand; if it is not, I think you have to implement something like that - the application that calls `cdb_trigger_subscriptions` also needs to watch for subscriber termination, or be somehow notified by the actual watchdog that a subscriber terminated.