JsonSerialisationOptions.Options applies DictionaryKeyPolicy to MessageHeader.Bag, breaking session-keyed delivery

[Jonny-Freemarket]

Describe the bug

Paramore.Brighter.JsonConverters.JsonSerialisationOptions.Options sets PropertyNamingPolicy = JsonNamingPolicy.CamelCase. DictionaryStringObjectJsonConverter applies that policy to dictionary keys as well as property names.

As a result, MessageHeader.Bag["SessionId"] is serialised as "sessionId". On the consume side, the ASB publisher does a case-sensitive Bag.TryGetValue("SessionId", out _) to decide whether to set ServiceBusMessage.SessionId. The lookup misses, the message is sent without a session, and the ASB broker silently drops it when the destination subscription has session-required = true.

Bag keys are arbitrary string identifiers, not C# property names — applying a property naming policy to them is semantically wrong, and the failure mode is fully silent (no exception, no log line, the message just never arrives).

To Reproduce

1. Configure a session-required ASB subscription.
2. Send a Brighter message whose MessageHeader.Bag["SessionId"] is set.
3. Round-trip the message through Brighter's STJ serialisation (e.g. via the scheduler envelope path, or any path using JsonSerialisationOptions.Options).
4. Observe the bag at the publisher: the key is now "sessionId".
5. Publisher's Bag.TryGetValue("SessionId", ...) misses → session-less message → silent drop.

Suggested fix

Set DictionaryKeyPolicy = null on JsonSerialisationOptions.Options (and any sibling options contributing to the envelope serialiser). Bag keys are user-defined identifiers and must round-trip verbatim.

(Alternative — case-insensitive lookup at fire time — papers over symptoms; the root issue is the bag's keys being mutated by a naming policy.)

Further technical details

• Brighter version: 10.4.1
• dotnet --info:

  .NET SDK 10.0.108 (commit 94ea82652c, MSBuild 18.0.11+94ea82652)
  Host 10.0.8 (x64)
  RID: win-x64
  

• OS: Windows 11 (build 10.0.26200)

[iancooper]

We have had some other bugs here. Could we get an agent to figure out why the change to dictionary keys was made as part of this? I worry that we might fix this, and see another pop up again, and be playing "whackamole" I agree with your thesis, that we should not change the bag keys, but I am wondering if it was a poor fix for another issue?

[DevJonny]

Will do @iancooper. This and the other three issues all came out of some investigation and work from one my teams. I got Claude to create the issues before I head on holiday so they wouldn't be stuck on my machine. I'm to having some quieter evenings this coming week to chat it over with Claude.