[W5UgxTqaij] Inactivity timeout triggered during long-running tool calls

[flexus-teams]

Problem Summary:
Inactivity timeout messages („Inactivity timeout after 2 minutes…") are being emitted while the assistant has active/long-running tool calls (e.g. web/vector_search) in progress. The user expects inactivity warnings to be sent only when the system is actually waiting for the user for >2 minutes, not while waiting for tool responses.

Evidence:

• messages.json (thread W5UgxTqaij): assistant initiated a vector_search tool call: ftm_num=28, ftm_created_ts=1760694172.741772 (contains ftm_tool_calls id call_39452461)
• tool result shows it "Timed out after 3612 seconds": tool message ftm_num=29, ftm_created_ts=1760697784.283551 (tool output: "Timed out after 3612 seconds"). This proves a long-running tool call was active.
• Immediately after, multiple inactivity cd_instruction messages were emitted: ftm_nums=30..50, ftm_created_ts=1760697960.459312. The cd_instruction content: "Inactivity timeout after 2 minutes. The task tMyKlF87tP is still assigned to this chat..." (repeated many times). These were sent while a tool call had been outstanding (or had just timed out), demonstrating the inactivity check did not consider the active tool call.
• messages.json also contains an earlier assistant tool call pattern and the sequence shows the inactivity messages were created while the system had tool activity in flight.

Root cause (analysis):
The inactivity timeout/scheduler logic treats the absence of new user/assistant messages as inactivity without checking whether there are pending tool calls. In other words, the inactivity detector only looks at elapsed time since last user/assistant activity and does not inspect thread state for in-flight tool calls (ftm_tool_calls or ft_need_tool_calls). As a result, long-running tool operations trigger the inactivity path and produce cd_instruction messages that are misleading and disruptive.

Suggested fix / next steps:

1. Change the inactivity-checking code to skip emitting "Inactivity timeout" while there exist active tool calls for the thread. Specifically:
   • Check for pending tool calls (messages with non-null ftm_tool_calls and no terminal tool response), or thread-level flags such as ft_need_tool_calls > 0 or timestamps like last_tool_call_ts vs last_tool_response_ts.
   • Only start the user-waiting timer when there are no in-flight tool calls.
2. Add a short debounce / dedupe for cd_instruction messages so multiple identical inactivity notices are not spammed (e.g., emit once, escalate once).
3. Add telemetry/logging to record when inactivity decisions are skipped due to active tool calls (so future debugging is simpler).
4. Add unit/integration tests which simulate long-running tool calls and assert that inactivity messages are not emitted during tool execution.

Please triage and assign to the component owning the scheduler/inactivity logic. If helpful, I can add a suggested patch diff for the inactivity scheduler.

-- Automated report from feedback dir: feedback/KJZCaw0FJC

@flexus-bob please take a look

[flexus-teams]

I've reviewed the issue and attempted to identify the relevant code for the inactivity scheduler logic in the flexus-client-kit repo. However, the claude_code tool encountered an error during execution, preventing me from analyzing the codebase and implementing the requested fixes (checking for pending tool calls before emitting timeouts, adding deduplication/logging, and tests).

Without access to the specific scheduler/timer modules (likely involving cd_instruction messages or thread state checks for ftm_tool_calls/ft_need_tool_calls), I can't proceed with targeted changes. This may require manual code review or providing more context on the file locations.

Triage note: Assign to the team owning the scheduler/inactivity logic for implementation.