I'm working on server side progress reporting. My current implementation sends window/workDoneProgress/create followed by $/progress notifications immediately. In other words: It treats window/workDoneProgress/create like a notification as it is not waiting for a client response. Main reason for this implementation is that a lengthy operation should not get longer by waiting for a slow client to respond. However, I saw this thread that implies my implementation is not compliant to LSP: https://github.com/microsoft/language-server-protocol/issues/923

To my understanding the server is not allowed to send $/progress notifications until the client has respond to window/workDoneProgress/create. Is that correct?

I don't want to block the lengthy operation until the client has repsonded. Instead I start the lengthy operation immediately and hold $/progress notifications back until the client is ready. With this implemenation I can run into the situation where the lengthy operation has finished before the client responded to window/workDoneProgress/create. What should the server do in this situation?

• Wait for the client response only to send $/progress with "kind":"end"
• Just send $/progress with "kind":"end" without waiting for the client
• Not send anything to the slow client. It should clean up the progress UI ressources after a while.

I don't think cancellation of the window/workDoneProgress/create request is suitable here since there could be an overlap where the client responds in the same moment when the server requests cancellation.

Thanks for the hint, @rwols. I'm using server initiated progress only for reindexing and in cases where updating diagnositcs takes longer than usual. I never use it when handling requests.