Hi, I was reviewing the current timeout behavior in rmcp and wanted to clarify whether the existing design is intentional.
From reading the code, request timeout appears to be enforced as a fixed wall-clock timeout in RequestHandle::await_response(), and on expiry rmcp emits a cancellation notification and returns a timeout error. At the same time, progress notifications seem to be handled independently as a dispatch/observation mechanism, and I could not find logic that refreshes or extends the request timeout when progress is received.
That raised a few questions for me.
Is it intentional that progress notifications do not affect request timeout semantics in rmcp?
If yes, what is the recommended model for long-running non-task requests that legitimately emit progress for a long time? Should clients always set a larger explicit request timeout, and reserve tasks for anything that may exceed that bound?
If no, would you be open to supporting optional progress-aware timeout behavior at the rmcp layer, such as resetting the request timeout on progress or supporting a pair of semantics like inactivity timeout plus max total timeout?
The reason I am asking is that downstream transports may need to retain correlation state while a request is still considered alive by rmcp. Without clear timeout semantics around progress, it is easy for transport-layer cleanup policies to drift from rmcp request lifetime.
I am not proposing a specific change yet. I mainly want to understand whether the current fixed-timeout behavior is a deliberate architectural choice or an area that is still open to evolution.
Hi, I was reviewing the current timeout behavior in rmcp and wanted to clarify whether the existing design is intentional.
From reading the code, request timeout appears to be enforced as a fixed wall-clock timeout in
RequestHandle::await_response(), and on expiry rmcp emits a cancellation notification and returns a timeout error. At the same time, progress notifications seem to be handled independently as a dispatch/observation mechanism, and I could not find logic that refreshes or extends the request timeout when progress is received.That raised a few questions for me.
Is it intentional that progress notifications do not affect request timeout semantics in rmcp?
If yes, what is the recommended model for long-running non-task requests that legitimately emit progress for a long time? Should clients always set a larger explicit request timeout, and reserve tasks for anything that may exceed that bound?
If no, would you be open to supporting optional progress-aware timeout behavior at the rmcp layer, such as resetting the request timeout on progress or supporting a pair of semantics like inactivity timeout plus max total timeout?
The reason I am asking is that downstream transports may need to retain correlation state while a request is still considered alive by rmcp. Without clear timeout semantics around progress, it is easy for transport-layer cleanup policies to drift from rmcp request lifetime.
I am not proposing a specific change yet. I mainly want to understand whether the current fixed-timeout behavior is a deliberate architectural choice or an area that is still open to evolution.