Proposal: make durable MCP submission compensation wait configurable

[AoHanBei]

Problem

PR #4933 protects cancellation compensation for durable MCP submissions.

When the caller is cancelled during local persistence, DeerFlow starts remote
compensation and currently waits for a fixed five-second deadline before
propagating the original cancellation. If the deadline expires, compensation
continues as a tracked background task.

The five-second value is currently hard-coded in app/mcp_tasks/service.py.

Different deployments may have different requirements:

• high-latency remote MCP services may benefit from a longer synchronous wait;
• shutdown-sensitive deployments may prefer a shorter wait;
• the current five-second behavior should remain the default.

Proposed scope

Add one restart-required setting under mcp_tasks, for example:

mcp_tasks:
  untracked_compensation_wait_seconds: 5

The setting would:

• default to 5 seconds, preserving current behavior;
• control only how long the caller waits for compensation;
• never cancel or abandon the compensation task when the deadline expires;
• preserve the original CancelledError;
• leave ordinary persisted cancellation retries unchanged.

Non-goals

• changing MCP tool_call_timeout;
• changing the remote cancellation protocol;
• adding dynamic config reload;
• changing persisted cancellation retry behavior;
• adding a database or API migration.

Validation

I would add deterministic coverage for:

• the default five-second configuration;
• invalid negative values;
• startup configuration wiring;
• a custom zero/short wait returning while compensation continues;
• repeated caller cancellation not extending the configured deadline.
  Would this narrowly scoped configuration capability be useful, or would you
  prefer to keep the five-second policy internal?

[willem-bd]

I support exposing this as a narrow, restart-required setting. The five-second wait is deployment policy rather than a correctness invariant, and preserving 5.0 as the default keeps the current behavior stable.

A few points should be clarified before implementation:

1. Background continuation is process-lifetime bounded. After the deadline, compensation remains only as a process-local task. McpTaskService.stop() does not currently drain _compensation_tasks, and event-loop teardown can cancel unfinished work. A shorter value can therefore make shutdown more likely to interrupt remote cleanup. Please either document the guarantee as “continues while the process remains alive,” or treat bounded shutdown draining as a separate lifecycle change.

2. The setting affects both finalization paths. _cancel_untracked_task is called for caller cancellation and for ordinary local submission-finalization failures. The description and regression coverage should include both, since this value also changes how long a persistence error is delayed before propagation.

3. Define strict configuration semantics. I suggest a finite bounded float with ge=0, default 5.0, and zero meaning immediate return while the tracked background compensation continues. Pass the startup snapshot into McpTaskService and store it on the instance rather than keeping a mutable module constant.

4. Follow the schema-update contract. This should update McpTasksConfig, Gateway construction wiring, config.example.yaml, configuration/MCP lifecycle guidance, and the config version. No database or API migration is needed.

5. Keep timing tests deterministic. In addition to the proposed default, invalid, zero/short, and repeated-cancellation cases, add coverage for the generic persistence-error branch and explicitly pin the chosen shutdown behavior. Prefer a controlled clock/deadline over sleep-sensitive assertions.

With those clarifications, the scope looks sound and useful.