Atlas Triggers

The producer side of every async ADB event is a MongoDB Atlas Trigger — a server-side function that watches a single collection's change stream and pushes a transformed message to AWS EventBridge (or, for two internal cases, to a Realm function). Triggers are NOT managed by the new infra/ Pulumi project — they live in the Atlas App Services app triggers-kkeqz and are deployed via realm-cli. The legacy management scripts are in adb-infrastructure/mongodb-atlas/realm-cli/triggers/.

At a glance

Details

Trigger inventory

Producer-side mapping (database, collection, operations watched):

The two notification Realm functions (superseded)

Together they used to perform the banner fan-out described in adb-utilities → Notification fan-out:

1. notification-definition-modified runs dev_notification_definition_created_updated_deleted_replaced_function.js: when the changed definition's state is NOTIFICATION_DEFINITION_STATE.ACTIVE it upserts { _id: <definition id>, organisationId, start: schedule.start } into notifications_ttl (a TTL index with expireAfterSeconds: 0 on start, see adb-infrastructure/mongodb-atlas/data-scripts/create_notifications_ttl_index.js); on a delete it removes that document.
2. notification-ttl-deleted runs dev_notification_ttl_deleted_function.js when MongoDB expires the TTL document: it loads the definition and insertManys one organisation-level notification per channel × organisation (organisationId = the target organisation, state: SENT, no user).

Both functions name the adb-development cluster service and were never provisioned for staging (adb-stage), the local stack or the Cloudflare port — which is why an activated banner reached no user there. Since 2026-09-23 adb-utilities performs this fan-out itself on every definition write (NotificationDefinitionServiceImpl#fanOut, property notifications.fan-out.enabled). Wherever the service fan-out is enabled these two triggers must be disabled (realm-cli → triggers-kkeqz), otherwise every banner is produced twice.

Database naming convention

Each microservice owns its own MongoDB database, named identically: adb-<service> (e.g. adb-contracts, adb-accounting). The adb-tickets database exists and triggers fire on it even though there's no adb-tickets/ directory in the monorepo today.

How to inspect or change a trigger

See MongoDB Atlas — Realm CLI setup for the install + auth steps. Then:

realm-cli login --api-key "$MONGODB_ATLAS_PUBLIC_API_KEY" --private-api-key "$MONGODB_ATLAS_PRIVATE_API_KEY"
realm-cli pull --remote triggers-kkeqz --local /tmp/realm
ls /tmp/realm/triggers
# Each <name>.json has config.{database,collection,operation_types} + event_processors.AWS_EVENTBRIDGE.config

To deploy a change, edit the JSON in the legacy adb-infrastructure/mongodb-atlas/realm-cli/triggers/ checkout (or in your realm-cli pull working copy) and realm-cli push --remote triggers-kkeqz.

Open questions

• Why does every trigger's project set event: "CREATED" and operationType: 1 as static literals? Real values should come from the change-stream metadata.
• Atlas Triggers don't appear in any IaC — they're managed by hand-edited JSON in adb-infrastructure/. Should they move to a Pulumi MongoDB Atlas provider integration so the new infra/ is the single deploy surface?
• The two notification-* triggers are superseded by the in-service fan-out (see above): when are they disabled on adb-prod, and is the notifications_ttl collection + TTL index dropped with them?