fix noma v2 deepcopy crashing in build scan payload - new PR

[omriShukrun08]

Relevant issues

Noma v2 integration experiences a 500 error during post_call/during_call/during_mcp_call due to deepcopy(request_data) failing on unserializable objects (uvloop.Loop) in _build_scan_payload. A JSON-safe copy method is needed, similar to the approach in spend_tracking_utils.py and its _sanitize_payload_for_transport() helper, which currently runs after the deepcopy crash.

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

Type

🐛 Bug Fix

Changes

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
4 out of 5 committers have signed the CLA.

✅ yuneng-berri
✅ mateo-berri
✅ TomAlon
✅ omriShukrun08
❌ idola9
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR fixes a 500 error in the Noma v2 guardrail by replacing deepcopy(request_data) with _sanitize_payload_for_transport(request_data) in _build_scan_payload, avoiding crashes when request_data contains C-extension objects (e.g. uvloop.Loop) whose __reduce__ raises on pickling. A regression test is included that verifies both the non-crash behavior and the non-mutation of the original dict.

Confidence Score: 4/5

Safe to merge; fix is correct and well-tested with only minor P2 concerns remaining.

The change is minimal and targeted, directly addresses the root cause (deepcopy crashing on unserializable objects), and does not affect the data that ultimately reaches Noma since _call_noma_scan always sanitizes the full payload. The regression test is solid. Two P2 issues exist: a missing RecursionError catch and a documentation gap around the double-sanitization pattern.

litellm/proxy/guardrails/guardrail_hooks/noma/noma_v2.py — specifically the exception handler in _sanitize_payload_for_transport

Important Files Changed

Filename	Overview
litellm/proxy/guardrails/guardrail_hooks/noma/noma_v2.py	Replaces deepcopy(request_data) with _sanitize_payload_for_transport(request_data) in _build_scan_payload to avoid crashes on C-extension objects like uvloop.Loop; two minor P2 issues noted (missing RecursionError in exception handler, post-sanitization injection of raw model_call_details).
tests/test_litellm/proxy/guardrails/guardrail_hooks/test_noma_v2.py	Adds a regression test for the deepcopy crash using a fake unpicklable object; no real network calls, correctly asserts non-mutation of the original dict and proper string fallback for unserializable values.

Sequence Diagram

sequenceDiagram
    participant Caller as apply_guardrail
    participant BSP as _build_scan_payload
    participant SPFT as _sanitize_payload_for_transport
    participant CNS as _call_noma_scan
    participant Noma as Noma API

    Caller->>BSP: request_data (may contain uvloop.Loop)
    BSP->>SPFT: request_data
    Note over SPFT: json.dumps with default=str fallback<br/>→ JSON round-trip → safe dict
    SPFT-->>BSP: payload_request_data (JSON-safe copy)
    BSP->>BSP: inject litellm_logging_obj (raw model_call_details)
    BSP-->>Caller: payload dict
    Caller->>CNS: payload
    CNS->>SPFT: payload (2nd sanitization pass)
    SPFT-->>CNS: sanitized_payload (litellm_logging_obj now safe)
    CNS->>Noma: POST /litellm/guardrail
    Noma-->>CNS: response JSON
    CNS-->>Caller: response_json

Loading

Comments Outside Diff (2)

1. litellm/proxy/guardrails/guardrail_hooks/noma/noma_v2.py, line 167-170 (link)

   RecursionError not caught in serialization fallback

   json.dumps will raise RecursionError (not ValueError/TypeError) on deeply-nested or self-referential structures in request_data. The current except (ValueError, TypeError) clause won't catch it, and the exception will propagate to the caller — the same 500 path this PR fixes.

2. litellm/proxy/guardrails/guardrail_hooks/noma/noma_v2.py, line 141-145 (link)

   model_call_details bypasses first sanitization pass

   _sanitize_payload_for_transport produces a clean JSON-safe dict at line 141, but model_call_details (a complex object) is injected back onto line 144 after the fact. The value is only sanitized later when _call_noma_scan calls _sanitize_payload_for_transport a second time on the full payload. This double-pass is harmless but the asymmetry is worth noting — if the call site ever changes to skip the second pass, litellm_logging_obj would contain unserialized data. Consider documenting that the second pass in _call_noma_scan is relied upon here.

_{Reviews (1): Last reviewed commit: "Fix spaces" | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!