Atlas App Services triggers use change streams to watch for document changes on a MongoDB database. Database triggers may enter a suspended state in response to an event that prevents the trigger’s change stream from continuing, such as a network disruption or changes to the underlying cluster. There are a number of scenarios in which a trigger becomes suspended:
Atlas App Services receives an invalidate event from the change stream, for example
Invalidateevents close the change stream cursor and prevent them from resuming.
The resume point/token which the trigger needs to use is no longer in the oplog.
A network error resulted in a communication failure and invalidation of the underlying change stream.
An authentication error where the Atlas database user used by the Atlas trigger is no longer valid, for example, if the App Services App is imported with
Typically, restarting the trigger establishes a new change stream against the watched collection. If you restart the trigger with a resume token, App Services attempts to resume the trigger’s underlying change stream at the event immediately following the last change event it processed. If successful, the trigger processes any events that occurred while it was suspended.
However, it is possible that the suspended trigger cannot be restarted with a resume token if the resume token is no longer in the oplog by the time the trigger attempts to resume (for example, due to a small oplog window). The solution is to restart the trigger without the resume token. If you do not use a resume token, the trigger listens for new events, but will not fire for any events that occurred while it was suspended. Ensure that your oplog size is sufficient (typically a few times more than the peak value from the Oplog GB / Hour graph in the cluster metrics view) in your cluster’s configuration to prevent the resume token from disappearing from the oplog in the future.
If the trigger suspension happens frequently, review the content mentioned above in detail and contact MongoDB Support.