Hi Simon,
Since MongoDB 4.4 is a major release which introduces new features and compatibility changes, there is an extended testing and release candidate phase. Release candidates are considered feature complete and ready for testing, with perhaps some polish left on new features or documentation. Any testing or feedback provided on release candidates is extremely helpful.
The release date is generally determined based on when the release is ready (for example, documentation complete and no known blocking issues). As Doug mentioned, we are currently at rc2 which is the third release candidate (release candidates start at rc0). As a general timescale guideline, the expectation for GA will be weeks or months from now rather than days or years.
For more details on what has changed, please see the Release Notes for MongoDB 4.4.
The specific issue you are focused on is about aggregation preferring indexes that can be used for sort (avoiding a blocking in-memory sort which may potentially fail). If you compare the explain output for equivalent find() versus aggregate() queries you will likely find that aggregation is choosing the _id index (or one which supports your sort criteria) over an index like {groups:1} (which is more selective but does not support the sort criteria). If you are able to share the explain output, someone might be able to provide a more informed suggestion.
Possible workarounds include:
- Add a compound index to support both your match and sort criteria (for example, on
{groups: 1, _id: 1})). - Hint the index to be used. The workaround on SERVER-21471 was from 2015, before aggregation hints were added in MongoDB 3.6.
Your aggregation pipeline may include more stages than the redacted example, but if it can be replaced by a find() query that would also be a straightforward solution.
Regards,
Stennie