-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: 8.2.4, 7.0.31, 8.2.6, 8.2.12
-
Component/s: None
-
None
-
Query Execution
-
ALL
-
-
None
-
None
-
None
-
None
-
None
-
None
-
None
$replaceAll with an empty find on a non ASCII string returns a value the client cannot read. The shell reports "Invalid UTF-8 string in BSON document" and a driver reports a decoding failure, so there is no usable result at all.
The replacement looks like it is inserted once per byte rather than once per character, which splits multi byte characters apart. Counting bytes in the reply was the only way I could see what was happening.
| Input character | Bytes in | Bytes out | Expected out |
|---|---|---|---|
| U+00E9 | c3 a9 | 58 c3 58 a9 58 | 58 c3 a9 58 |
| U+4E16 | e4 b8 96 | 58 e4 58 b8 58 96 58 | 58 e4 b8 96 58 |
| U+1F600 | f0 9f 98 80 | 58 f0 58 9f 58 98 58 80 58 | 58 f0 9f 98 80 58 |
0x58 is the letter X. ASCII input is fine, so "ab" returns "XaXbX".
The second line of the output shows $substrBytes returning an error rather than a broken string for the same kind of input. SERVER-6801 was the same problem in $substr and was resolved by returning an error.
Expected
One insertion before and after the character, giving a two character result, or an error.
Actual
A value that is not valid UTF-8. Clients reject the whole reply, so the query cannot be used and there is no partial result to fall back on.
- is related to
-
SERVER-6801 aggregation $substr expression can output invalid UTF8
-
- Closed
-