# Channel Faulting in 1.2.0beta

**URL:** <https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385>\
**Category:** Uncategorized\
**Created:** [October 23, 2019, 6:26pm UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385 "2019-10-23T18:26:25Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ianbmacdonald](https://avatars.discourse-cdn.com/v4/letter/i/b2d939/32.png) [@ianbmacdonald](https://forum.genieacs.com/u/ianbmacdonald)\
**Post date:** [October 23, 2019, 6:26pm UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385/1 "2019-10-23T18:26:25Z")

</div>

In the 1.2.0beta, we notice that when our provision faults, like in the following example for an undefined value, there are fault messages for all of the channels, rather than just the one the provision is linked to in its preset.

In hindsight, the channel ‘provision’ needs a better name, perhaps ‘provisioning’.

We suspect maybe this is a known issue, so just posting here to confirm this behaviour will likely change in the release candidate.

2019-10-23T18:22:04.192Z [WARN] 10.5.1.203 3c9066-963168\_OT142C\_B-3c90667da870: Channel has faulted; channel=“default” retries=0 faultCode=“script.ReferenceError” faultMessage=“provError is not defined”  
2019-10-23T18:22:04.192Z [WARN] 10.5.1.203 3c9066-963168\_OT142C\_B-3c90667da870: Channel has faulted; channel=“inform” retries=0 faultCode=“script.ReferenceError” faultMessage=“provError is not defined”  
2019-10-23T18:22:04.192Z [WARN] 10.5.1.203 3c9066-963168\_OT142C\_B-3c90667da870: Channel has faulted; channel=“provision” retries=0 faultCode=“script.ReferenceError” faultMessage=“provError is not defined”  
2019-10-23T18:22:04.218Z [WARN] 10.5.1.203 3c9066-963168\_OT142C\_B-3c90667da870: Channel has faulted; channel=“provision” retries=1 faultCode=“script.ReferenceError” faultMessage=“provError is not defined”

---

<div class="post-metadata">

**Author:** ![zaidka](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/zaidka/32/9_2.png) [@zaidka](https://forum.genieacs.com/u/zaidka)\
**Post date:** [October 25, 2019, 9:42pm UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385/2 "2019-10-25T21:42:15Z")

</div>

This is actually not a bug. Genie combines declarations from all channels into a single profile before applying it. When a fault happens it assumes all active channels failed, then retries them individually and clear the fault if they pass. So although you see 4 fault log entries, you should end up with a single faulty channel at the end of the session.

---

<div class="post-metadata">

**Author:** ![chauhan.ns](https://avatars.discourse-cdn.com/v4/letter/c/58956e/32.png) [@chauhan.ns](https://forum.genieacs.com/u/chauhan.ns)\
**Post date:** [February 25, 2020, 7:12am UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385/3 "2020-02-25T07:12:59Z")

</div>

Hello,

Is there any recovery mechanism for any faulted channel.  
Let’s say I have a channel named “channelx” associated with a preset “presetx” and provision “provisionx”.  
The periodicity of presetx is “2 PERIODIC”.  
If the provision script in provisionx fails due to some error (e.g. some coding error  
in the provision script), and the error was corrected before next INFORM.

Will provisionx gets triggered during next and subsequent periodic INFORM?

---

<div class="post-metadata">

**Author:** ![akcoder](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/akcoder/32/11_2.png) [@akcoder](https://forum.genieacs.com/u/akcoder)\
**Post date:** [February 25, 2020, 5:27pm UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385/4 "2020-02-25T17:27:33Z")

</div>

Yes, there is a built-in retry and back-off mechanism for faults.

---

<div class="post-metadata">

**Author:** ![chauhan.ns](https://avatars.discourse-cdn.com/v4/letter/c/58956e/32.png) [@chauhan.ns](https://forum.genieacs.com/u/chauhan.ns)\
**Post date:** [February 26, 2020, 5:04am UTC](https://forum.genieacs.com/t/channel-faulting-in-1-2-0beta/385/5 "2020-02-26T05:04:39Z")

</div>

Thank you Dan, for the confirmation 🙂
