[release/6.0] Fix Ordinal Ignore Case string compare #71158
Conversation
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
Tagging subscribers to this area: @dotnet/area-system-globalization Issue DetailsBackport of #71022 to release/6.0 /cc @tarekgh Customer ImpactThis is a regression that occurred in .NET 6.0. Users who try to sort a list of strings using ordinal ignore casing option, can run into a problem getting unexpected strings order. We have fixed this in .NET 7.0. TestingHave done manual testing to ensure we are getting the right behavior. I have added more tests to ensure I catch this problem if it happens again in the future. The change has passed all regression tests. RiskIt is low as it is scoped to the failing case only and fixing the behavior. I am not expecting this change to cause any harm or affect anything else. IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
|
Tactics would like to hold on this backport pending evidence of wider impact. Noted that the customer reporting this has a workaround. |
ghost
locked as resolved and limited conversation to collaborators
Backport of #71022 to release/6.0
/cc @tarekgh
Customer Impact
Customer reported regression in .NET 6. Sorting with ordinal ignore case results in different behavior compared to .NET 5.0 and .NET Framework. This is limited to the case with non-ASCII strings containing characters support casing. This is difficult for the customer to debug and could surface in many cases like deserialization across frameworks or user app depends on some algorithms like binary trees or sorting.
Example of the broken behavior, when sorting
ѰaandѰB,ѰBwill come beforeѰaAlthough there is only one report, as sorting is a fundamental operation it's likely that other customers are hitting this but aren't aware.
Testing
Have done manual testing to ensure we are getting the right behavior. I have added more tests to ensure I catch this problem if it happens again in the future. The change has passed all regression tests.
Risk
It is low as it is scoped to the failing case only and fixing the behavior. I am not expecting this change to cause any harm or affect anything else.
IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.