Repository navigation
Fix exception thrown when streaming certain XML values via XmlReader - #4757
Conversation
This closes a bug where UTF-16 XML streams not starting with '<' could be detected incorrectly as UTF-8, causing exceptions on reading.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
@dotnet-policy-service agree |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The fix is focused and adequately covers synchronous, asynchronous, sequential, and buffered reader paths; the documentation comment is non-blocking.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Fixes XML fragment streaming by explicitly decoding SQL XML streams as UTF-16LE.
Changes:
- Supplies an
Encoding.Unicodeparser context when creating XML readers. - Expands regression tests to cover fragments beginning with text.
| File | Description |
|---|---|
SqlTypeWorkarounds.cs |
Explicitly configures UTF-16LE decoding. |
DataReaderStreamsTest.cs |
Adds fragment-focused coverage and serialization support. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This change was suggested by Copilot review: dotnet#4757 (comment)
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #4757 +/- ##
==========================================
- Coverage 71.96% 64.66% -7.31%
==========================================
Files 291 286 -5
Lines 45110 68405 +23295
==========================================
+ Hits 32462 44231 +11769
- Misses 12648 24174 +11526
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
I assume this PR is still in review and not waiting on any action from me. If I am mistaken, just let me know. Thanks! |

Description
This PR fixes an exception thrown when streaming certain
xmlvalues.When an
xmlvalue streams from the database server, it streams as BOM-less UTF-16LE, according to my experiments. When SqlClient constructs anXmlReaderto present that value to the caller (for example, insqlDataReader.GetXmlReader(…)), SqlClient does not specify the encoding. Instead, the default encoding detection logic applies. That logic detects UTF-16LE when the stream begins with a BOM or a<; otherwise that logic assumes UTF-8. Because anxmlvalue can be an XML fragment, there existxmlvalue BOM-less UTF-16LE streams that the detection logic will detect wrongly as UTF-8. One such value is:foo<bar/>Some SqlClient code paths that return an
XmlReaderinstance apply aSqlStreamwrapper that synthesizes a BOM, ensuring that the detection logic detects UTF-16LE. Other code paths do not, and the detection logic is free to detect UTF-8 incorrectly. In that case, the returnedXmlReaderthrows an exception on the first call toxmlReader.Read(), as the reader becomes confused by what it sees as aNULevery second character. That is the bug.This PR alters
XmlReaderconstruction to set the encoding to UTF-16LE (Encoding.Unicode) explicitly, thus directly bypassing the encoding detection logic and avoiding the bug.Once the fix is in place, the
SqlStreamBOM-synthesizing behavior might be removable. In the interest of focus, that is left for a possible future PR.This PR carries no API changes and no documentation impact.
Issues
Closes #4756.
Testing
This PR modifies the following test methods in
DataReaderStreamsTest(manual tests, set 2) to test for this fix:GetFieldValueAsync_OfXmlReaderGetFieldValue_OfXmlReaderGetXmlReaderSpecifically, this PR prefixes the root-level text
footo testxmlvalues so that anXmlReaderconstructed without an explicit encoding will encounter the pathological case in the encoding detection logic.