fix: handle duplicate keys in logger state to prevent ArgumentException

[hjgraca]

Please provide the issue number

Issue number: #956

Summary

Changes

Fixes issue where requests with duplicate headers caused:
"An item with the same key has already been added. Key: Content-Type"

Replaces ToDictionary() with manual dictionary population to handle duplicate keys that can occur with HTTP headers (e.g., multiple Content-Type headers).
The last value wins for duplicate keys, maintaining existing behavior.

• Replaced ToDictionary() with manual dictionary population using indexer assignment
• Last duplicate key value wins (maintains existing semantic behavior)
• Performance improvement: O(n) vs O(n log n) complexity
• No LINQ overhead or intermediate collections

Added test case Log_WhenDuplicateKeysInState_LastValueWins() that verifies:

• Duplicate keys don't throw exceptions
• Last value wins for duplicates

User experience

Please share what the user experience looks like before and after this change

Checklist

Please leave checklist items unchecked if they do not apply to your change.

• Meets tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.45%. Comparing base (dd6d208) to head (9232e86).
⚠️ Report is 19 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #961      +/-   ##
===========================================
+ Coverage    77.39%   77.45%   +0.06%     
===========================================
  Files          271      271              
  Lines        10874    10886      +12     
  Branches      1282     1284       +2     
===========================================
+ Hits          8416     8432      +16     
  Misses        2041     2041              
+ Partials       417      413       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[phipag]

Do we need to consider this recursively for nested keys as well or will this not raise an ArgumentException. For example:

{
    "key1": {
        "val": "some_val",
        "val": "some_other_val"
    } 
   "key2": "some_val"
}

[hjgraca]

Do we need to consider this recursively for nested keys as well or will this not raise an ArgumentException. For example:

{
    "key1": {
        "val": "some_val",
        "val": "some_other_val"
    } 
   "key2": "some_val"
}

Good question, no it will not, for this case the key has to be unique, the value part is not considered in this code. If the value part is indeed a dictionary, the same rules apply (unique key) but they are not responsibility of this code and have to be fixed by the dictionary creator.

[phipag]

Do we need to consider this recursively for nested keys as well or will this not raise an ArgumentException. For example:

{
    "key1": {
        "val": "some_val",
        "val": "some_other_val"
    } 
   "key2": "some_val"
}

Good question, no it will not, for this case the key has to be unique, the value part is not considered in this code. If the value part is indeed a dictionary, the same rules apply (unique key) but they are not responsibility of this code and have to be fixed by the dictionary creator.

Got it, makes sense. We are only dealing with appending the top level keys here and the values are handled by the user. Thanks!