Consider the following distinct command against a collection "c":
The expected response is that there are two distinct values, 1 and 2. If we create an identity view on top of "c" and run the same distinct against the view, the results are incorrect:
Instead of getting two distinct values, 1 and 2, we get a single distinct value [1, 2]. This bug is due to how the distinct command is internally expanded into an aggregation operation by the read-only non-materialized views implementation. In particular, it expands to an $unwind followed by a $group with $addToSet such as this:
The problem lies in the behavior of the $unwind stage, added to the distinct-to-agg transformation in
SERVER-27644. Note what happens when we run this same pipeline without the $group stage:
When the $unwind path traverses through an array, but does not terminate at an array, no unwinding actually occurs. This is at odds with the distinct command's behavior, which expects all arrays along the path to be unwound. Fixing this will likely involve extending the expressivity of $unwind to meet the needs of the distinct command.