I have a Platform Event trigger in my managed package. For some reason, it generated an error on a customer's sandbox, and now it's in error state and won't run.

I updated the trigger and pushed the new managed package to this org, but the trigger still shows error state.

The docs say "To resume processing of new event messages, fix and save the trigger."... but this is a managed package, so there's no way to open/save the trigger to reset things. Not sure how to proceed...


I've seen several discussions around this issue but no clear recommendation. Certainly not one that is well suited to ISV development.

Post from Chuck Liddell in the Official: Platform Events success group:

For a normal Platform Event trigger that moves into the Error State (stops listening) because of errors, you can edit the trigger code, save, and the trigger will subscribe again.

However, a subscriber to a managed package cannot edit the trigger code for a managed trigger. If a managed trigger moves into Error State, how can the package subscriber restore it?

Compiling all Apex, re-installing the package, and upgrading the package all do not seem to work, ...

And a more recent post related specifically to the Winter '20 release.

I've got multiple customers in a panic because their previously-stable Apex triggers on Platform Events are tripping into error mode repeatedly because of exceeding replay attempts. None of these triggers use the ReplayException mechanics.

The following was posted by Chuck on the GDS slack -

Any Apex trigger on a Platform Event will unsubscribe from that event (move into an error state) if it hits too many retries. I'm a little fuzzy on the exact behavior of this, as I've seen it happen several times in the last few weeks and not just on triggers that do something with EventBus.RetryableException. The error message you get is The Apex trigger YourTrigger on platform event YourEvent__e has exceeded the maximum number of retry attempts. The trigger is now in the error state and has stopped processing new events.

Normally (for non-ISVs) to resolve this you figure out why you had errors, fix them in your trigger code, and save it. Obviously, this is a little tricky for managed packages.

I've done some testing, and simply installing again, or upgrading to a later version, does not turn the trigger back on. Neither does compiling all Apex in the subscriber org. A full uninstall and reinstall will, of course, work but that's pretty much a non-option for most circumstances.

The only way to turn the trigger back on is to make any edit to your trigger, including whitespace, and include that change in your next packaged version. And finally, we arrive at my advice: I'm going to recommend that any managed package that has Apex triggers on Platform Events add a script to their deployment process to touch / add whitespace to these Triggers on every version release.

A little ham-handed, perhaps, but the benefit is that every update to a later version of your package will allow a customer to turn triggers back on if they have turned off for some reason.

It is probably worth revisiting creating a new package version that includes a modification to the trigger in question. By all accounts that should reactivate it. It's still not an ideal solution long term.

Salesforce Docs on Email Notifications for Triggers in Error State

  • I've also tried the PM on twitter. It does seem like a bit of a gap for ISVs. Oct 6 '19 at 21:58
  • thanks for the comprehensive research! I have, in fact, updated the Trigger and pushed the new package version, but the error does not clear. I'm not sure if Chuck is recommending a post-install Apex script to make that update to the trigger? Is that what he's saying. I didn't know that would be possible. Oct 7 '19 at 0:37
  • @PatMcClellan__c I don't think a post install script can update the trigger metadata. It would be a security nightmare if production code could update other production code. I think he just meant that something significant enough would change in the trigger with each package version so it shows up as being changed. Is it possible that the trigger is reactivating and then going back into the error state fairly quickly? Oct 7 '19 at 0:50
  • Nope, the is on the event doesn't change, nor the datetime. Oct 7 '19 at 1:00

FIXED! According to tech support...

In winter'20 release, there was additional functionality added for retrying the Platform event trigger without the EventBus.RetryableException implementation.

The change - In case of any Limit exceptions while Platform event trigger is executing then the platform trigger context will be retried for 10 times similar to EventBus.RetryableException implementation.

As the issue started due a feature addition in Platform event and was reverted back from the release.


Error was occurring from managed package Trigger. It needs to fix in managed package trigger, redeploy the package after fixing the trigger.

The trigger has been disconnected and stopped receiving published events. A trigger reaches this state when it exceeds the number of maximum retries with the EventBus.RetryableException

  • Did all of that, but the trigger of the same name, even when updated, is locked out. Oct 7 '19 at 3:38
  • And, btw, my code does not use the EventBus.RetryableException, so there's no reason the trigger should have been re-trying or caused an error. Oct 7 '19 at 18:27

If you are okay with writing an Un-managed trigger, then you can write the same trigger in Sandbox and deploy it to the client. Create a custom setting to disable the existing managed trigger and upgrade the client org.

  • 1
    I dont think this would help, Being an ISV one cannot move code from sandbox/prod to sandbox just package upgrades. Oct 9 '19 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.