[Bug] Converter returns bad value converting `dict[None, Any]`

[tconley1428]

What are you really trying to do?

I don't know why this would be a thing.

Describe the bug

In test_converter.py,
ok(dict[None, str], {'null': "1"}) passes, but that doesn't really seem like the correct return object.

Minimal Reproduction

Environment/Versions

• OS and processor: [e.g. M1 Mac, x86 Windows, Linux]
• Temporal Version: [e.g. 1.14.0?] and/or SDK version
• Are you using Docker or Kubernetes or building Temporal from source?

Additional context

[VivekVRobo]

Hi, I’d like to take another look at this, specifically addressing the compatibility concern raised on the earlier #1677 before writing a patch.

I traced the current converter path. The inconsistency comes from how the two equivalent annotations expose their key type:

• dict[None, str] -> key argument is the literal None
• typing.Dict[None, str] -> key argument is NoneType

The mapping converter treats a falsy/literal None key type as if no key type were specified, so the JSON key "null" is left as a string. The typing.Dict spelling already takes the NoneType branch and restores it to the Python None key.

My compatibility argument for fixing this is:

1. The current result for dict[None, T] violates the declared key type by returning str keys.
2. Python's JSON encoder serializes a None mapping key as "null", so restoring "null" to None is the natural typed round trip.
3. The legacy-equivalent typing.Dict[None, T] already has that behavior today, so the fix would make PEP 585 and typing.Dict spellings consistent rather than introduce a new semantic.
4. The compatibility risk is limited to callers that declared dict[None, T] but nevertheless relied on receiving the wrong str key after deserialization. I agree this is still observable behavior, so I would call it out explicitly in the changelog.

If maintainers agree that this justification is sufficient, my proposed scope is small:

• normalize literal None to NoneType only when selecting a mapping key converter;
• update the existing known-bug assertion so dict[None, str] and typing.Dict[None, str] have parity;
• add a focused negative case showing a non-"null" JSON key is rejected for a None key annotation;
• add a JSON payload round-trip regression so this is tested at the public converter boundary, not only through value_to_type;
• add the required changelog entry.

I would avoid touching unrelated Literal[None], Optional/Union handling, or general mapping conversion.

Would you consider that compatibility justification sufficient to accept a focused PR?