The current spec appears to have an idempotency hole where the client may crash after sending a request and before it receives and persists the server-generated contextId & taskId. In that case, the client has no way of knowing if a task was started on its behalf and subsequently querying the status of that task. I believe the original spec had a 'tasks/send' method which allowed the caller to specify the taskId to support idempotency. It seems that this change was made for security purposes (eg to prevent unauthorized interaction between clients) - is that correct? Either way, I believe security and idempotency are not mutually exclusive.
I also understood from the spec & C# implementation that the messageId property is informational only. I.e, it has no behavior associated with it. Is that correct?
See also #926 - this PR makes the server-generated nature of identifiers more explicit.
Code of Conduct
The current spec appears to have an idempotency hole where the client may crash after sending a request and before it receives and persists the server-generated
contextId&taskId. In that case, the client has no way of knowing if a task was started on its behalf and subsequently querying the status of that task. I believe the original spec had a 'tasks/send' method which allowed the caller to specify thetaskIdto support idempotency. It seems that this change was made for security purposes (eg to prevent unauthorized interaction between clients) - is that correct? Either way, I believe security and idempotency are not mutually exclusive.I also understood from the spec & C# implementation that the
messageIdproperty is informational only. I.e, it has no behavior associated with it. Is that correct?See also #926 - this PR makes the server-generated nature of identifiers more explicit.
Code of Conduct