Docs Menu
Docs Home
/
MongoDB Atlas
/
Atlas App Services
/
Triggers

Disable a Trigger

On this page

  • Overview
  • Restoring from a Snapshot

Overview

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 change to the underlying cluster. When a Trigger enters a suspended state, it does not receive change events and will not fire.

Note

In the event of a suspended or failed trigger, Atlas App Services sends the project owner an email alerting them of the issue.

You can suspend a Trigger from the Atlas App Services UI or by importing an application directory with the App Services CLI.

1

Find the Trigger

On the Database Triggers tab of the Triggers page, find the trigger that you want to disable in the list of Triggers.

A list of Triggers in an App in the App Services UI
2

Disable the Trigger

Switch the Enabled toggle to the "off" setting.

The "Edit Trigger" screen in the App Services UI
click to enlarge
3

Deploy Your Changes

If Development Mode is not enabled, press the review draft & deploy button to release your changes.

1

Pull Your App's Latest Configuration Files

appservices pull --remote=<App ID>
2

Verify that the Trigger Configuration File Exists

If you exported a new copy of your application, it should already include an up-to-date configuration file for the suspended trigger. You can confirm that the configuration file exists by looking in the /triggers directory for a trigger configuration file with the same name as the trigger.

3

Disable the Trigger

After you have verified that the trigger configuration file exists, add a field named "disabled" with the value true to the top level of the trigger json definition:

{
   "id": "6142146e2f052a39d38e1605",
   "name": "steve",
   "type": "SCHEDULED",
   "config": {
      "schedule": "*/1 * * * *"
   },
   "function_name": "myFunc",
   "disabled": true
}
4

Deploy Your Changes

Finally, push the configuration back to your app:

appservices push

Restoring from a Snapshot

Consider the following scenario:

  1. A database trigger is disabled or suspended.

  2. New documents are added while the trigger is disabled.

  3. The database is restored from a snapshot to a time prior to the new documents being added.

  4. The database trigger is restarted.

In this case, the trigger picks up all of the newly-added documents and fires for each document. It will not fire again for events that have already been processed.

Note

If a previously-enabled database trigger is running during snapshot restoration, you will see an error in the Edit Trigger section of the Atlas UI because the trigger cannot connect to the Atlas cluster during the restore process. Once snapshot restoration completes, the error disappears and the trigger continues to execute normally.

Back

Scheduled Triggers

Next

Send Trigger Events to AWS EventBridge