fix(relay): sanitize null JSON Schema required values in tool definitions across protocols

[LIghtJUNction]

Upstream source

• QuantumNous/new-api PR: fix(tools): drop invalid null "required" from tool schemas QuantumNous/new-api#7531
• Upstream head: 14ce52319f90281437b0a259858afbe4c752b775
• Affected upstream files:
  • relaykit/relayconvert/internal/toolconv/decode.go
  • relaykit/relayconvert/internal/toolconv/schema_sanitize.go
  • relaykit/relayconvert/internal/toolconv/schema_sanitize_test.go

Problem

JSON Schema requires required to be an array of property names. Some clients emit "required": null in function/tool schemas. Strict upstreams reject the whole request; upstream #7531 reports this with xAI, Moonshot and Xiaomi MiMo.

The intended compatibility repair is to drop a null required member (not replace it with []), including nested schema nodes, while preserving valid required arrays.

api.lmm.best gap

Current main does not yet have upstream's unified relayconvert/internal/toolconv.ExtractRequest funnel, so #7531 cannot be safely cherry-picked.

Relevant current shapes are split by protocol:

• OpenAI Chat: dto.GeneralOpenAIRequest.Tools []ToolCallRequest; FunctionRequest.Parameters is any.
• Claude Messages: dto.ClaudeRequest.Tools is any; tool input_schema can retain required: null.
• OpenAI Responses: tool payload is retained as raw/dynamic JSON in the request DTO/conversion path.
• Gemini has its own function-declaration conversion path.

A one-protocol patch would leave equivalent failures in the other routes. Sanitizing arbitrary request JSON globally would also be too broad and could mutate non-tool payloads or explicit pass-through behavior.

Recommended LMM-native implementation

Add one protocol-neutral tool-schema sanitizer at the relay conversion/request-normalization boundary that is invoked for decoded OpenAI Chat, OpenAI Responses, Claude Messages and Gemini requests before an upstream-compatible request is emitted.

Rules:

1. Only sanitize function/tool JSON Schema payloads (parameters, input_schema, Gemini function declaration parameters, Responses function parameters), not arbitrary request objects.
2. Recursively remove a key only when the key is exactly required and its value is JSON null.
3. Preserve valid arrays, empty arrays, strings/numbers/booleans, properties, items, $defs/definitions, combinators and unknown schema keywords unchanged.
4. Bound recursion/depth (upstream uses 64) so malformed/hostile schemas cannot cause unbounded stack growth.
5. Do not invent required: []; absence is the compatibility representation.
6. Preserve explicit raw pass-through semantics: if the channel/request is configured for byte-for-byte pass-through, do not silently rewrite its body unless we make that behavior an explicit compatibility option.
7. Keep pricing, groups, model price lock, /fast, OAuth restrictions, provider selection and admin AI assistant behavior untouched.

Acceptance criteria

• Claude /v1/messages tool with top-level input_schema.required: null is forwarded without required and no longer fails strict OpenAI-compatible upstreams.
• OpenAI Chat function tool with function.parameters.required: null is sanitized.
• OpenAI Responses function tool with parameters.required: null is sanitized.
• Gemini function declaration with parameters.required: null is sanitized when converted/forwarded.
• Nested null required values under objects/arrays/combinators are removed.
• A valid required: ["path"] and required: [] remain byte-equivalent semantically.
• Non-tool JSON containing a field named required: null is not rewritten.
• Tests cover recursion depth and malformed/non-schema values.
• Existing relaykit conversion tests and Go CI pass.

Why issue first instead of direct port

Upstream #7531 is newly opened and its CI workflow currently requires action rather than being fully green. More importantly, LMM's current relaykit predates the upstream unified toolconv extraction layer, so a direct port would either miss routes or broaden rewriting too far. This should be implemented against LMM's current normalization boundary as one small cross-protocol compatibility patch rather than copied mechanically.

[LIghtJUNction]

Upstream #7531 added a follow-up commit after this issue was filed: QuantumNous/new-api@57c28f6

This materially tightens the sanitizer contract. The first implementation recursively walked every map/array, which would also delete a legitimate required: null stored as instance data under JSON Schema keywords such as default, examples, const, enum, or vendor extensions. The fix now recurses only through schema-valued keywords:

• single subschema: additionalItems, additionalProperties, contains, else, if, items, not, propertyNames, then, unevaluatedItems, unevaluatedProperties
• subschema arrays: allOf, anyOf, items (legacy tuple form), oneOf, prefixItems
• maps of subschemas: $defs, definitions, dependentSchemas, patternProperties, properties

Everything else is treated as opaque JSON.

Please add these regression requirements to the LMM-native implementation:

1. required: null is removed at the schema node itself and below the schema-valued keywords above.
2. Literal { "required": null } nested under default, examples, const, enum, or x-* vendor data survives unchanged.
3. Do not implement this as an unrestricted recursive walk over all maps/arrays, even after the sanitizer has already been scoped to tool parameters.

Current LMM main still has no equivalent sanitizer and no PR references #479, so this remains the single tracking item. Upstream head is now 57c28f6fed4559a31a040b7b2de8423f9a2c3edb; its CodeRabbit status is still pending.

[LIghtJUNction]

Upstream #7531 added another follow-up commit after the previous note: QuantumNous/new-api@247f041

This closes two remaining schema-walk gaps in the sanitizer:

• contentSchema is itself a subschema-valued keyword, so nested required: null inside it must be sanitized.
• Draft-07 dependencies is a map whose values can be either subschemas or arrays of property names. Only map-valued entries are schemas and should be walked; array-valued dependency lists such as {"a":["b","c"]} are instance/keyword data and must remain untouched.

Please extend the LMM-native acceptance tests accordingly:

1. Remove nested required: null under contentSchema.
2. Remove nested required: null in map-valued Draft-07 dependencies entries.
3. Preserve array-valued Draft-07 dependencies byte-for-byte semantically.
4. Keep the previous rule that non-schema payloads under default, examples, const, enum, and vendor extensions are opaque.

Current LMM main is still d6dae2c3781391d0e9faeb7a7d052d33aa4c0df9, there is still no branch/PR implementing #479, and no duplicate tracking item was found. Upstream head is now 247f0413e1132bf018742e01c0b2d7db269eae23; CodeRabbit reports review completed successfully.