[SERVER-52866] Handle getLastError and resetError during tenant migrations Created: 13/Nov/20 Updated: 06/Dec/22 Resolved: 17/Nov/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jason Zhang | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | pm-1791_milestone-A | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Sharding
|
||||||||
| Participants: | |||||||||
| Description |
|
getLastError is the legacy way for a user to find out if their write replicated to the desired number of replicas. getLastError is implemented by having the primary cache lastError information in memory per Client, which corresponds to a particular connection. Therefore, the lastError information is lost on restart. I think we should not support getLastError in serverless, since it's a legacy feature that doesn't work across restart and would require extra work to transfer the in-memory data to the recipient. |
| Comments |
| Comment by Blake Oler [ 16/Nov/20 ] |
|
FWIW, we don't need to handle resetError. We're removing that command in |