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

• I agree to follow this project's Code of Conduct