Docs Menu
Docs Home
/ /
Atlas App Services
/

Disable a Trigger

On this page

  • Overview
  • Find the Trigger
  • Disable the Trigger
  • Deploy Your Changes
  • Pull Your App's Latest Configuration Files
  • Verify that the Trigger Configuration File Exists
  • Disable the Trigger
  • Deploy Your Changes
  • Restoring from a Snapshot

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

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

Switch the Enabled toggle to the "off" setting.

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

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

1
appservices pull --remote=<App ID>
2

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

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

Finally, push the configuration back to your app:

appservices push

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