[SERVER-31453] Retryable writes do not support 32-bit transaction ids Created: 06/Oct/17 Updated: 27/Oct/23 Resolved: 08/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | 3.5.13 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Shane Harvey | Assignee: | Kaloian Manassiev |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
The retryable writes design doc and drivers spec both say that a transaction id may be a 32-bit or 64-bit positive integer. However, the server currently rejects 32-bit transaction ids: CC: jmikola |
| Comments |
| Comment by Kaloian Manassiev [ 08/Oct/17 ] |
|
As part of the design review we decided that txnNumber is more descriptive than txnNum so we changed the parameter name, but forgot to update all places in the design. So, txnNumber is the correct parameter name and I will update the design specification to include that. In terms of supporting 32-bit or 64-bit integers, we did some math and figured that 32-bit integers theoretically can roll over within some "human-scale" time period (a few months). So instead of handling that, we should just make the value 64-bit and not worry about it. Because of this, we decided also to go the simple route and only expect 64-bit integers, instead of trying to cast other numerical types. |