[CDRIVER-4634] Avoiding Errors if Change Stream Events Exceed 16MB Created: 02/May/23 Updated: 14/Aug/23 |
|
| Status: | Backlog |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | PM Bot | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Server Compat: | 7.0 | ||||||||||||||||
| Upstream Changes Summary: | DRIVERS-2617:
Drivers with strongly-typed change stream events will have to add accessors for the new splitEvent field. Note that it was a design decision to require application authors to programmatically handle the fragments. Each fragment will have its own resume token. Thus application authors will have to handle the case that the pre- and post-images can be returned in separate fragments. We will make no attempt to combine multiple fragments into a single change stream event as this can have additional consequences. For example, let's say a large event was split into 3 fragments, what is the expected behaviour if we are combining the fragments into a single event? 1. Do we block until all three fragments are received? In summary we should expose the splitEvent field and require application authors - who have opted into large event processing - to handle the edge cases explicitly by processing the fragments themselves. |
||||||||||||||||
| Description |
|
This ticket was split from DRIVERS-2617, please see that ticket for a detailed description. |