RedisSession history replacement is not atomic: compaction can leave the session empty

Finding: In openai-agents-python 0.23.1 and main @ 71c2da4, per the reporter, compaction on a RedisSession can expose an empty or partial history to concurrent readers and can leave the session permanently empty if the process is killed mid-compaction. This is an external report only; KFA did not reproduce it. Source: https://github.com/openai/openai-agents-python/issues/5329. Reported conditions: standalone Redis 7 (redis:7-alpine), redis-py 8.1.0, Python 3.12.12, macOS arm64, with a fake responses.compact client. The reporter says the legacy whole-history replacement in OpenAIResponsesCompactionSession runs clear_session() and then add_items(output_items) as two separate Redis writes. This path applies to manual run_compaction() and to backends lacking _get_compaction_snapshot, which the reporter says includes RedisSession (issue #5329). Reported measurements: during 50 compactions a concurrent reader observed list lengths of 0, 1 and 500 on both 0.23.1 and main. Under random SIGKILL, the session was left empty in 14 of 60 trials on main and 15 of 60 on 0.23.1. The reader case reproduced on every run per the reporter. These are one reporter's local results (EXTERNAL_REPORT). The reporter notes that existing restore-on-error handling covers exceptions and cancellation but not process death, and that the Session protocol exposes only get_items, add_items, pop_item and clear_session, so applications that rewrite history themselves face the same gap. They reference #5103, which added an atomic replace_suffix for SQLiteSession. Proposed directions (HYPOTHESIS, not confirmed by maintainers): implement _get_compaction_snapshot with a transactional replace_suffix for RedisSession, or add an optional atomic replace_items on sessions that the compaction wrapper prefers (issue #5329). A non-collaborator comment describes a fork commit adding RedisSession._atomic_replace_items using WATCH plus MULTI/EXEC, with the compaction session preferring it when present, and claims new tests and a regression subset pass. The author says they could not open a PR. This is an unreviewed, unmerged third-party patch; no maintainer confirmation, merged commit or release was supplied (https://github.com/openai/openai-agents-python/issues/5329#issuecomment-6057233739). Status: open, no confirmed maintainer cause, no released fix. Practical implication: until a fix ships, treat Redis-backed compaction as non-atomic with respect to concurrent readers and abrupt process termination. No verified safe workaround was supplied.