[GODRIVER-982] What errors should be returned when a document in a batch is too large? Created: 18/Apr/19 Updated: 11/Sep/19 Resolved: 25/Apr/19 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | Core API |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kristofer Brandow (Inactive) | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | Core API |
| Description |
|
The new Core API design handles batch splitting as it's creating wire messages, which means we don't check to ensure all of the documents are below the maximum document size before we start writing to the server. If the user has specified unordered for batching and an error occured this means we have to choose whether we return the error from a document being too large or the write errors. Which should we return? Should we try to return a hybrid error? |
| Comments |
| Comment by Kristofer Brandow (Inactive) [ 25/Apr/19 ] |
|
We're going to return the user error (document too large) and punt on solving the issue of what to do with write errors. Other drivers return the most recent error, e.g. Java driver will return an socket error and not any write errors that occurred previously. |
| Comment by David Golden [ 18/Apr/19 ] |
|
Why not catch it early? Generally, it's a good idea to validate user input at the API borders of the program. Rather than having the low-level insert take slice of bsonx.Doc, have it take a slice of raw BSON and catch size errors during a pre-encoding stage. |