Dear MongoDB/Mongoose maintainers,

I am writing to propose a new feature that I believe would enhance the utility and flexibility of MongoDB's Change Streams.

Problem

In scenarios where MongoDB Change Streams are being used to sync two databases, a potential issue of recursive loops arises. For instance, consider a system that has two databases (DB1 and DB2) being synced. An operation (like an insert or update) on DB1 triggers a change event that is captured by the Change Stream. This event leads to a corresponding operation on DB2. However, this operation on DB2, in turn, triggers another change event on DB1, thereby potentially causing an infinite loop of updates.

At present, to circumvent this issue, developers need to devise multiple guards or checks to prevent these infinite loops. However, this process can be complex and error-prone and can clutter the code with numerous conditionals.

Proposed Solution

I propose the addition of an option in MongoDB/Mongoose operations (like insert, update, etc.) that allows these operations to be 'invisible' to Change Streams. This would provide a straightforward way to break the loop in database syncing scenarios by ensuring that an operation meant as a response to a Change Stream does not itself produce a new change event.

 

For instance, the API for an insert the operation could look like this:
{{db.collection.insertOne(document,

{ bypassChangeStream: true }

);}}
 

Other Use Cases

1. Bulk operations: During bulk data operations, developers might want to prevent each operation from triggering a change event to avoid flooding the change stream.

1. Temporary or intermediate updates: In some workflows, there might be temporary updates to the database that need not be propagated through the Change Stream.

1. Testing scenarios: This could be useful in test suites where certain operations are performed purely for testing and do not need to trigger a Change Stream event.

Next Steps

I appreciate the potential implications of this change, and I understand that it might require substantial modifications to the MongoDB and Mongoose codebase. I am eager to discuss this proposal further and, if the community finds this feature beneficial, I am willing to contribute to its implementation.