Details
-
Bug
-
Resolution: Unresolved
-
Major
-
3.0.0-alpha5, 2.7.11
-
None
-
1
Description
Currently, expiration throughout the stack is stored as a uint.
As covered in https://docs.microsoft.com/en-us/dotnet/api/system.uint32.maxvalue?view=netframework-4.8, the highest value for a uint is 4294967295.
In epoch time, 4294967295 is Sunday, 7 February 2106 06:28:15.
If you set a timespan greater than this value, then the ToTtl() override will silently cause an overflow and set the incorrect expiration time.
For example:
TimeSpan deleteDate = TimeSpan.FromDays(365 * 94); // 94 year timespan
|
var dateExpiry = DateTime.UtcNow + deleteDate;
|
var unixTimeStamp = dateExpiry.Subtract(new DateTime(1970, 1, 1)).TotalSeconds;
|
Console.Out.WriteLine($"Date: {dateExpiry}");
|
Console.Out.WriteLine($"Calculated Epoch Seconds: {unixTimeStamp}");
|
Console.Out.WriteLine($"ToTtl() Result: {deleteDate.ToTtl()}");
|
Returns the following output, demonstrating the overflow:
Date: 7/27/2113 1:10:30 PM
|
Calculated Epoch Seconds: 4530604230.19981
|
ToTtl() Result: 235636934
|
The net effect of this is that documents will not appear in Couchbase Server as they'll instantly be expired.
Obviously longer term (3.0 timeframe?) we may want at using something larger than an uint to represent expiration, to allow higher expirations to be used?
In the short term we should not silently underflow in ToTtl(), instead if the timespan is too big, perhaps we could fail with a clear and obvious error?
Attachments
Issue Links
- relates to
-
JCBC-1478 Setting expiry too far into the future creates issues
- Closed