First thing, you’ve used the terms “disabled” and “suspended” interchangeably so I just want to make sure: how are you checking to see if the trigger is getting suspended?
Disabling a trigger and suspending it are two different things. It’s not uncommon for people to accidentally switch these terms but it’s important to understand the difference. After the retries get exhausted, the trigger’s document processing will be suspended but the trigger remains enabled. To see whether the trigger has been suspended, please go to the Trigger Management page on the IS Admin Console.
Assuming for now that the trigger is indeed not getting suspended, here are two general thoughts based on your code:
You may be mixing up a couple of ideas. You do NOT have to call the monitoring service from your trigger/processing service. I suppose you could but that wasn’t the intention. The IS will start calling the monitoring service once your trigger gets suspended. As soon as the monitoring service returns isAvailable = true, the IS will automatically resume your trigger.
Your BRANCH statement is currently problematic. According to your BRANCH statement, your service will always end in an exception because you’re using a $default label on the EXIT $flow and signal FAILURE step.
Now… just to make sure we’re not getting ahead of ourselves, let’s do this:
- Change your trigger so that it retries 0 times
- Remove the monitoring service from your trigger settings
This will ensure that once you call throwExceptionForRetry, your trigger will get suspended right-away and it will remain suspended.
With this done, go ahead and change your processing service so that all it does is call throwExceptionForRetry. If you want, you can add a call to debugLog or tracePipeline in the beginning so you can easily check from the log whether your service was executed.
With this in place, your trigger should get suspended no matter what. So, go ahead and publish a document. Did it get suspended? If so, then you can now start adding your logic back in and testing it as you move along. If the trigger stops behaving as you would expect it to, it should then be easier for you to pinpoint what code or configuration change caused the issue.