Summary

Some drivers parse change stream documents into language types.

Proposed change is to avoid parsing errors of change stream events that prevent:

• Server from adding new values to operationType.
• Server from adding fields.
• Users from applying projection.

Motivation

Some drivers parse operationType as an enumeration and throw an error if parsing an unrecognized operationType. See this spreadsheet for a list of affected drivers.

That behavior necessitated an opt-in flag for adding new change stream events in PM-1950. PM-1950 makes the assumption that introducing new change stream event types does not break user applications.

Drivers should permit new fields to allow extension. C# throws on extra fields in the ns subdocument. The ns document could have fields added in the future. E.g. viewOn.

One motivation is to avoid opt-in flags when adding events in the future.

Another motivation is to allow users to apply a $project stage. The server errors if _id is projected out. Users should be free to add, remove or modify any other fields in the change stream event as they see fit.

Who is the affected end user?

Permitting unrecognized operationType permits the server to add change stream events with a new operationType without breaking existing user applications. Allowing extra fields permits the server to extend change stream events in the future. Permitting missing / modified fields permits the user to apply $project.

How does this affect the end user?

If new operationType values result in an error, it requires the server to add new change stream events behind an "opt-in" flag.

If there is no "opt-in" flag, user applications will error when a server upgrade occurs before a driver upgrade. Example:

• Atlas upgrades the backing server
• User is stuck on an old driver that does not recognize the new operationType
• Change stream iteration errors when the new event is produced.

How likely is it that this problem or use case will occur?

The query team believes it is likely that new change stream events will be added in the future.

If the problem does occur, what are the consequences and how severe are they?

If this is not done before PM-1950, the server will need to continue to add change stream events behind additional "opt-in" flags.

Is this issue urgent?

This ticket should be done on the timeline of PM-1950. That will enable all future events to be behind the one "opt-in" flag introduced in PM-1950.

Is this ticket required by a downstream team?

Possibly Shell.

Is this ticket only for tests?

No. This has functional impact.