fix: handle escaped dots in nested paths

[alifelham]

Relevant issues

No duplicate issue or pull request found after searching for escaped dotted-key deletion behavior

Linear ticket

Pre-Submission checklist

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

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review)

Screenshots / Proof of Fix

Before at 265bf871bcb85ef09466b59d1cd93b02d2a0f79e

$ LITELLM_LOCAL_MODEL_COST_MAP=True python -c 'from litellm.litellm_core_utils.dot_notation_indexing import delete_nested_value; data = {"metadata": {"trace.id": "remove", "keep": "value"}}; print(delete_nested_value(data, r"metadata.trace\.id"))'
{'metadata': {'trace.id': 'remove', 'keep': 'value'}}

After at 638b5e92

$ LITELLM_LOCAL_MODEL_COST_MAP=True python -c 'from litellm.litellm_core_utils.dot_notation_indexing import delete_nested_value; data = {"metadata": {"trace.id": "remove", "keep": "value"}}; print(delete_nested_value(data, r"metadata.trace\.id"))'
{'metadata': {'keep': 'value'}}

Type

Bug Fix

Changes

Updates nested-path parsing so an escaped dot remains part of a field segment and is unescaped before dictionary traversal

Adds a regression test for deleting a literal dotted key while preserving sibling data

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

This PR fixes _parse_path_segments so that an escaped dot (\.) in a JSONPath-like string is treated as part of the key name rather than a segment separator, then unescaped before dictionary traversal.

• The regex is updated from r"[^\.\[]+" to r"(?:\\\.|[^\.\[])+", letting \. sequences be consumed as a unit, with a post-findall pass to unescape. Behavior for paths without escaped dots is identical to before.
• Three new tests cover the original reported bug (nested dotted key), a top-level dotted key, and a key with multiple escaped dots.

Confidence Score: 5/5

This PR is safe to merge — it makes a minimal, targeted change to a single utility function with no effect on callers that use unescaped paths.

The regex change correctly handles the new escape syntax while preserving identical behavior for all existing paths that don’t contain \.. The three new tests cover the originally reported bug, a top-level dotted key, and a multi-dot key.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/litellm_core_utils/dot_notation_indexing.py	Updated _parse_path_segments regex to treat \. as part of the field name rather than a separator, then unescape it before traversal; return type narrowed to list[str]. Change is logically correct and backward-compatible.
tests/test_litellm/litellm_core_utils/test_dot_notation_indexing.py	Three new regression tests added: nested key with escaped dot (original bug), top-level key with escaped dot, and key with multiple escaped dots — all with docstrings, addressing previous review feedback.

_{Reviews (2): Last reviewed commit: "test: cover escaped dotted path edge cas..." | Re-trigger Greptile}

[alifelham]

@greptileai

[alifelham]

This PR is ready for maintainer review

The focused core utility tests, lint checks, and coverage checks pass, Greptile scored it 5/5, and there are no unresolved review threads

The three remaining CI failures appear unrelated to this change:

• documentation and code-quality fail on the base branch because mcp_rpm_limit is missing from the update_team docstring, tracked in docs(team): document mcp_rpm_limit in update_team docstring #33475
• osv-scan fails because the July 15 OSS daily base contains the vulnerable ddtrace version; build(deps): update ddtrace to the 4.x line #33484 has merged the upgrade, but that change is not yet in this PR's base branch

This PR changes neither the affected documentation nor dependencies

Could a maintainer review the implementation and confirm whether these base-branch failures can be disregarded or rerun after the OSS daily branch is refreshed?