Looking at backend/agents/agent_run_manager.py, I'm puzzled by the bookkeeping around _conversation_run_counts. It's incremented in register_agent_run (line 43) and decremented in unregister_agent_run (lines 54-56), but then it's only read inside clear_conversation_context_manager (line 100) via pop, where the value is discarded entirely:
def clear_conversation_context_manager(self, conversation_id: Union[int, str]):
"""Explicitly clear the ContextManager for a conversation."""
conv_key = str(conversation_id)
with self._lock:
cm = self._conversation_context_managers.pop(conv_key, None)
self._conversation_run_counts.pop(conv_key, None)
if cm:
logger.info(...)Two related questions:
-
Is _conversation_run_counts meant to gate auto-cleanup? I'd expect something like "when the count hits zero, also clear the ContextManager so a long-lived process doesn't leak per-conversation memory" — but no such logic exists. As written, the counter is updated but otherwise dead.
-
If the counter is meant to be eventual / informational, why hold the lock to decrement it? Compare with get_agent_run_info (line 65) which reads self.agent_runs without the lock — so the class is already mixing locked-write/unlocked-read patterns and the counter's contribution is unclear.
A grep over backend/ and sdk/ shows no other reads of _conversation_run_counts. Either this is genuinely vestigial (in which case it can be deleted) or there's an intended behaviour that was never wired up (in which case it should be).
Happy to send a PR either way — just want to confirm intent before nuking it.
Looking at
backend/agents/agent_run_manager.py, I'm puzzled by the bookkeeping around_conversation_run_counts. It's incremented inregister_agent_run(line 43) and decremented inunregister_agent_run(lines 54-56), but then it's only read insideclear_conversation_context_manager(line 100) viapop, where the value is discarded entirely:Two related questions:
Is
_conversation_run_countsmeant to gate auto-cleanup? I'd expect something like "when the count hits zero, also clear theContextManagerso a long-lived process doesn't leak per-conversation memory" — but no such logic exists. As written, the counter is updated but otherwise dead.If the counter is meant to be eventual / informational, why hold the lock to decrement it? Compare with
get_agent_run_info(line 65) which readsself.agent_runswithout the lock — so the class is already mixing locked-write/unlocked-read patterns and the counter's contribution is unclear.A grep over
backend/andsdk/shows no other reads of_conversation_run_counts. Either this is genuinely vestigial (in which case it can be deleted) or there's an intended behaviour that was never wired up (in which case it should be).Happy to send a PR either way — just want to confirm intent before nuking it.