[Bug]: MergePatchUpdate omits the null branch on Record values, so per-key deletion fails validation

[SnowboardTechie]

Describe the bug

The MergePatchUpdate doc comment says the transform follows RFC 7396, "applying the merge-patch transform recursively to keyed types" in the resource model. That recursion doesn't happen for a Record<T> field, which is a keyed type: the field itself is transformed, its values are emitted unchanged.

An optional record does become nullable, so the whole map can be cleared, but deleting a single key fails validation. The algorithm in RFC 7396 recurses into nested objects and treats null as a delete instruction at every level, so both of these are valid merge patches:

{"tags": null}         // clear the whole map
{"tags": {"a": null}}  // delete one key

Only the first validates. Per-key deletion cannot be expressed against the generated schema at all. Since the template also sets application/merge-patch+json as the request content type, that schema is what tells a client what the server accepts.

Versions: @typespec/compiler 1.14.0, @typespec/http 1.14.0, @typespec/openapi3 1.14.0.

Reproduction

import "@typespec/http";

using Http;

@service(#{ title: "Record repro" })
namespace RecordRepro;

model Widget {
  name: string;
  tags?: Record<string>;
}

model WidgetPatch is MergePatchUpdate<Widget>;

@route("/widgets/{id}")
@patch
op update(@path id: string, @body body: WidgetPatch): Widget;

Emitted WidgetPatch:

type: object
properties:
  name:
    type: string
  tags:
    anyOf:
      - type: object
        unevaluatedProperties:
          type: string   # <- no null branch
      - type: 'null'     # <- the field itself is clearable

Validating patch bodies against that schema:

VALID    {"name":"x"}
VALID    {"tags":null}
VALID    {"tags":{"a":"b"}}
INVALID  {"tags":{"a":null}}

Expected: the transform reaches the record's values, so unevaluatedProperties accepts T | null and the last case validates as "delete key a".

[SnowboardTechie]

Related: #11534, the other MergePatchUpdate conformance gap.

[github-actions]

🎯 Issue Triage

MergePatchUpdate<T> does not recurse into Record<T> values when generating the merge-patch schema, so per-key deletion (setting an individual map entry to null) fails validation even though RFC 7396 requires it.

Category: Bug
Area: lib:http

🔗 [Playground Reproduction]((typespec.io/redacted)

📋 Reproduction code

import "`@typespec/http`";

using Http;

`@service`(#{ title: "Record repro" })
namespace RecordRepro;

model Widget {
  name: string;
  tags?: Record<string>;
}

model WidgetPatch is MergePatchUpdate<Widget>;

`@route`("/widgets/{id}")
`@patch`
op update(`@path` id: string, `@body` body: WidgetPatch): Widget;

🔍 Analysis

• Affected component: MergePatchUpdate template in @typespec/http
• Root cause: The merge-patch transform makes optional Record<T> fields nullable (allowing the whole map to be cleared), but does not recursively apply the transform to the record's value type T. RFC 7396 requires null to be a valid value at every level of a nested object, meaning individual map entries should also accept null to signal deletion.
• Expected behavior: unevaluatedProperties in the emitted schema should be T | null (e.g., string | null) so that {"tags": {"a": null}} is a valid merge patch expressing "delete key a".
• Related: Reporter notes [Bug]: MergePatchUpdate keeps allOf on the unpatched base, so an empty merge patch is rejected #11534 as another MergePatchUpdate conformance gap.

📝 Suggested next steps

• Update MergePatchUpdate (or its underlying transform utility) in @typespec/http to recurse into Record<T> value types, making them T | null in the generated schema.
• Add a test case covering Record<T> fields with per-key null deletion.
• Verify fix with the reproduction above and confirm emitted unevaluatedProperties includes a null branch.

Generated by Agentic Triage

[markcowl]

Technically, Merge-Patch only specifies how to determine the intention of the user for the request, not whether the request will be accepted by the server. For example, if there is no 'a' property in the record, it's not in the specification whether the server is required to accept this request or return a 400 response.

I agree that allowing null seems to make more sense, since the default behavior is likely to ignore properties that don't exist, and the request is syntactically correct, regardless.