# Trigger and Function Anti-Patterns > Source-anchored research for Trigger and Function Anti-Patterns. Run status: COMPLETED. Parent: [MongoDB Atlas Triggers and Functions](https://llms-explorer.com/tree/mongodb-atlas-triggers-and-functions/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/trigger-and-function-anti-patterns/ ## How it works - Raising trigger concurrency without checking downstream capacity can exceed external API rate limits and increase database workload. MongoDB also warns that unordered execution trades guaranteed event order for parallelism; treating concurrency as a free performance improvement is unsafe. (low confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/database-triggers.md) - Treating Trigger delivery as exactly once makes non-idempotent side effects unsafe: Atlas documents possible duplicate deliveries after failures. Design repeated handling to be safe. Google's separate Atlas-backed serverless example demonstrates duplicate inserts and event-ID uniqueness as one defense; it does not establish Atlas Function retry semantics. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers.md) - Raising Trigger concurrency without checking downstream API quotas can overload external services or increase cluster load. MongoDB explicitly warns about both effects; its general guidance also recommends reducing network calls and filtering irrelevant events before invocation. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/database-triggers.md) ## Problems, failure modes and limitations - Assuming a failed Atlas Function automatically retries is an anti-pattern: the documented Function runtime has no built-in retry behavior. Custom recursive retries need a maximum attempt count and may need throttling; all recursive attempts share one invocation's execution budget. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/functions/handle-errors.md) - Logging credentials is a concrete risk when adapting tutorials: Autodesk's example prints newly issued access and refresh tokens. MongoDB also documents that Function arguments are logged by default and provides a switch to disable that logging. Review both explicit log statements and automatic argument logging before passing secrets. (high confidence) — [source](https://aps.autodesk.com/blog/maintaining-refresh-tokens-mongodb-triggers) - For failure visibility, OneUptime's logging example records structured error data and rethrows the exception so execution is marked failed. Its advice supports treating catch-and-log-only handlers as an observability risk; rethrowing alone does not provide automatic Atlas Function retries. (medium confidence) — [source](https://oneuptime.com/blog/post/2026-03-31-mongodb-atlas-trigger-logs-monitor-debug/view) - Relying on application-user data rules to constrain Database or Scheduled Trigger code is an anti-pattern. These triggers execute as a system user, and MongoDB documents that system execution bypasses rules, roles, and permissions. Autodesk's trigger example also explicitly notes full system-user access. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/functions.md) - A unique event-ID index prevents duplicate inserts, but does not by itself guarantee a notification is delivered exactly once. In Google's sample, a notification failure after insertion is followed by a retry that returns on duplicate key before notifying again. This limitation follows from the published code, not a demonstrated Atlas Trigger defect. (low confidence) — [source](https://cloud.google.com/blog/products/databases/best-practices-and-tutorial-using-google-cloud-functions-mongodb-atlas) ## Comparisons and alternatives - Writing changes back into a watched scope can create recursive Trigger chains, including cross-trigger chains. MongoDB warns about this configuration and supports match expressions that filter the events which invoke Functions. Filter out the Function's own output changes rather than invoking on every update. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/database-triggers.md) - Assuming failed Atlas Functions automatically retry is an anti-pattern. MongoDB explicitly documents no built-in Function retries and describes custom bounded retry mechanisms. This differs from Trigger event redelivery after infrastructure failures; redelivery is not a substitute for application retry design. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/functions/handle-errors.md) - Unbounded recursive retries can exhaust a Function execution. MongoDB recommends a retry count limit and optional throttling; retries within one invocation share its runtime budget. Recursive retry logic must therefore stop rather than keep calling indefinitely. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/functions/handle-errors.md) - Keeping event ordering enabled for slow Functions during bursts can build a backlog because executions run sequentially. Disabling ordering permits parallel processing but loses execution-order guarantees. Treat ordering as an explicit correctness and throughput tradeoff. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-ui/triggers/database-triggers.md) ## Facts and statements - A scheduled Function that serially processes an entire growing collection can exceed its runtime. Autodesk explicitly warns that its all-user token-refresh example may time out at scale; MongoDB documents a 300-second Function runtime cap. Bound the work performed in each invocation. (high confidence) (verified as of 2026-10-14) — [source](https://aps.autodesk.com/blog/maintaining-refresh-tokens-mongodb-triggers) - The statement that every same-collection update necessarily loops is too broad. MongoDB's engineering example shows that setting already-equal values can leave the document unchanged. Recursion depends on producing another matching change; repeatedly changing timestamps or other fields still needs an explicit guard. (medium confidence) — [source](https://dev.to/mongodb/mongodb-optimizes-updates-to-the-same-value-1f2k)