Litellm memory improvements v2

[krrish-berri-2]

Relevant issues

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

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-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.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Screenshots / Proof of Fix

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

This PR refines the memory PUT endpoint's handling of metadata: null: previously an explicit null was silently discarded (and a null-only payload returned 400), now it is encoded as the JSON literal "null" and written to the jsonb column, so callers receive metadata: null on the next read. The UI delete-confirmation flow is also upgraded from an imperative Modal.confirm call to the shared DeleteResourceModal component with a required-key confirmation step.

Confidence Score: 4/5

Safe to merge; all findings are P2 quality/consistency notes, no runtime-breaking issues.

Only P2 findings: a SQL NULL vs jsonb null asymmetry between the PUT create and update code-paths (cosmetically transparent to callers today but could matter for future db-side filtering), and a minor test coverage gap. No security issues, no backwards-incompatible breakage of existing callers.

litellm/proxy/memory/memory_endpoints.py — review the create-path null handling around line 503 relative to the update-path change.

Important Files Changed

Filename	Overview
litellm/proxy/memory/memory_endpoints.py	Changes metadata: null handling in PUT from a no-op to an active write (JSON "null" → jsonb 'null'), fixing silent discard; minor SQL NULL vs jsonb null asymmetry exists between create and update paths within the same PUT handler.
tests/test_litellm/proxy/memory/test_memory_endpoints.py	Tests updated to reflect new explicit-null-clears semantic; renames and assertion changes are intentional, not regression-hiding; small gap in null-metadata-only test (value field not re-asserted).
ui/litellm-dashboard/src/components/MemoryView/MemoryView.tsx	Replaces inline Modal.confirm delete flow with the shared DeleteResourceModal component; adds deleteRow state, confirmDelete handler, and a requiredConfirmation keyed on deleteRow.key for safer UX.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["PUT /v1/memory/{key}"] --> B{Row exists?}
    B -- No --> C["Create path\nif metadata is not None → JSON-encode\notherwise omit → SQL NULL"]
    B -- Yes --> D["Update path\nif 'metadata' in model_fields_set\n→ json.dumps(metadata)\n→ NULL → 'null' string → jsonb null"]
    D --> E{data dict empty?}
    C --> F["prisma.create(data)"]
    E -- Yes --> G["HTTP 400"]
    E -- No --> H["prisma.update(where=memory_id, data=data)"]
    H --> I["_row_to_model → response"]
    F --> I

Loading

Comments Outside Diff (2)

1. litellm/proxy/memory/memory_endpoints.py, line 492-504 (link)

   SQL NULL vs jsonb null inconsistency in PUT create vs update paths

   When a PUT request creates a new row (existing is None), the create-path on line 503 still guards with if body.metadata is not None:, meaning an explicit {"value": "x", "metadata": null} on a new key stores a true SQL NULL. But if the same key already exists, the update-path (line 452) writes the JSON literal "null" → jsonb 'null'. Both deserialize to Python None on reads, but they differ in SQL — WHERE metadata IS NULL matches SQL NULL but not jsonb 'null', and WHERE metadata = 'null'::jsonb matches the opposite. If any current or future query filters on nullness of the metadata column, rows created via PUT with metadata: null and rows updated via PUT with metadata: null will behave differently.

2. tests/test_litellm/proxy/memory/test_memory_endpoints.py, line 700-706 (link)

   Missing assertion that value is preserved after null-metadata-only PUT

   test_put_memory_null_metadata_alone_clears_field sends {"metadata": null} without a value, but only asserts that metadata becomes None. It doesn't verify that the stored value field (originally "v") is still "v" after the update. Adding assert resp.json()["value"] == "v" and assert table.rows[0].value == "v" would guard against a regression where a partial-update accidentally clears unincluded fields.

_{Reviews (1): Last reviewed commit: "Merge branch 'litellm_internal_staging' ..." | Re-trigger Greptile}