[SERVER-53528] createIndexes rounds expireAfterSeconds option on latest servers Created: 28/Dec/20 Updated: 27/Oct/23 Resolved: 08/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dmitry Lukyanov (Inactive) | Assignee: | Gabriel Marks |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Execution Team 2021-11-15 |
| Participants: |
| Description |
|
The createIndexes behavior on latest servers was changed. Now, when I send this command:
the actually created index contains rounded expireAfterSeconds value. This is what I see via getIndexes for the above command:
Was this intentional change? If it was I guess it should have generated a downstream changes notification. |
| Comments |
| Comment by Gabriel Marks [ 08/Nov/21 ] |
|
This change was caused by this commit: https://github.com/mongo/mongo/commit/b83bf99b6e48e2f41ea3b1e7ed6aeb4cf1eb0d31 Specifically, the changes to the list indexes command (list_indexes.cpp) cause the index specs which are written by the create indexes command to be run through IDL validation before they are returned by list indexes, so the value of 1.5 for expireAfterSeconds which is stored in the spec by index creation is passed through the safeNumberInt BSONElement conversion function, causing it to be truncated to 1 in the list indexes output. However, this is in fact working as expected, because although 1.5 is stored in the index spec, everywhere expireAfterSeconds is actually used, it is truncated to an integer anyways, so the value returned from list indexes is representative of the actual value used by the server. In later commits, a similar change was done to the create indexes command so that this incorrect un-truncated value is not written to the index spec at all. |
| Comment by Dianna Hohensee (Inactive) [ 28/Oct/21 ] |
|
We should figure out when this happened and how, so we can return the server to prior behavior – what number type did we use before? Moving a parser over to an IDL could have changed the parameter type. I recommend adding a JS test to ensure this behavior does not accidentally change again in future, since it has downstream impact. |
| Comment by Dmitry Lukyanov (Inactive) [ 11/Jan/21 ] |
|
jeff.yemin, we have such ticket for c#: https://jira.mongodb.org/browse/CSHARP-3294 . Not sure whether any other drivers have such tests. if yes, then they could use this ticket, no - if they don't have such tests. Anyway, I didn't close it now |
| Comment by Jeffrey Yemin [ 11/Jan/21 ] |
|
dmitry.lukyanov should we use this ticket to track the change required in our tests? |