[lisry-1]

Summary

RedisHistoryProvider.get_messages deserialized every Redis list entry without per-entry error handling. A single empty string or corrupt JSON entry would raise JSONDecodeError / ValueError and abort the entire read, even when the remaining entries were valid.

CosmosHistoryProvider.get_messages already handles this case by skipping malformed entries with a warning (see _history_provider.py in azure-cosmos).

Change

Wrap each entry in try/except (ValueError, json.JSONDecodeError), log a warning, and continue, matching the Cosmos behavior. Added a regression test that feeds ["", "not-json", <valid>] and asserts the valid message is still returned.

[Copilot]

🟡 Changes recommended

Valid JSON entries with malformed message shapes can raise uncaught exceptions that abort the entire history read, preventing later valid messages from being returned.

1 open issue

• Malformed message entries abort the entire read · New

What changed in this PR

This PR makes the Python Redis history provider more resilient by skipping entries that raise JSON decoding or value errors instead of aborting the entire history read.

Changes:

• Add per-entry error handling and warning logs to get_messages.
• Add a regression test confirming valid messages remain readable after empty or invalid JSON entries.

File	Description
python/​packages/​redis/​tests/​test_providers.py	Tests recovery from empty and invalid JSON history entries.
python/​packages/​redis/​agent_framework_redis/​_history_provider.py	Catches deserialization value errors and logs skipped entries.

_{Review effort: Balanced}

[Eduard van Valkenburg (eavanvalkenburg)]

Thanks for the contribution, lisry-1. The code review is clean, but this changes malformed-history handling from fail-fast to skip-and-warn, so the PR needs the required Related Issue answer before approval. Please link an agreed issue with a closing keyword, or document a maintainer-approved exception. Missing AI Assistance alone is not a blocker.

[lisry-1]

Thanks Eduard van Valkenburg (@eavanvalkenburg). I've opened #9974 to track this bug and linked it in the PR's Related Issue section (Fixes #9974). This is a self-contained defect fix — the Redis provider diverges from the existing Cosmos provider behavior — so I've documented the issue as the agreed requirement. Please let me know if the issue needs a ready-for-implementation label or any further confirmation before you can proceed with approval. Happy to adjust.

[Eduard van Valkenburg (eavanvalkenburg)]

lisry-1 The new warning logs str(exc) from deserializing an untrusted Redis history payload. Message.from_dict includes the supplied type value in mismatch errors, so private history data embedded there can be copied into application logs even though the malformed entry is skipped. Please log a safe failure category or exception class instead of exception text, and add a regression asserting that sensitive payload values are absent from the warning.

[lisry-1]

Eduard van Valkenburg (@eavanvalkenburg) thanks for catching that — you're right, str(exc) could copy untrusted history data into application logs, since Message.from_dict embeds the payload's type value in mismatch errors.

I've pushed a fix:

• The skip warning now logs the exception class (type(exc).__name__) instead of str(exc), so no payload-derived value reaches the log.
• Added test_malformed_entries_do_not_leak_payload_in_logs, which stores a payload with type: "secret-internal-token" and asserts the warning is emitted while the sensitive value is absent from it.