Ask questionsHow to handle progress finished when the client has not yet responded to window/workDoneProgress/create?

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:

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.


Answer questions Wosi

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.

Github User Rank List