Many operations can take a long time in some situations. As a real example, some of the HLS formatting options relied on getting the build options for the project, which required setting some things up, which can take a little while. This means that if e.g. a user has format-on-save set up, then they will get blocked on save until the setup is complete.
Now, in this situation it seems clear that the formatting should just get timed out quickly. The question is whose responsibility that is:
It could be the server's: the server could decide that it's not good enough if formatting takes more than (say) 1s, and return a failure for that request.
It could be the client's: the client could decide that formatting shouldn't take more than 1s, and cancel the request if it does.
My instinct is to say that it's the client's responsibility. In particular, in this example the acceptable time for a request to take is probably different for user-initiated formatting vs format-on-save, but this distinction is not visible to the server. So this aspect of UX responsiveness is probably in the client's court. But I thought it was interesting to talk about!
Many operations can take a long time in some situations. As a real example, some of the HLS formatting options relied on getting the build options for the project, which required setting some things up, which can take a little while. This means that if e.g. a user has format-on-save set up, then they will get blocked on save until the setup is complete.
Now, in this situation it seems clear that the formatting should just get timed out quickly. The question is whose responsibility that is:
My instinct is to say that it's the client's responsibility. In particular, in this example the acceptable time for a request to take is probably different for user-initiated formatting vs format-on-save, but this distinction is not visible to the server. So this aspect of UX responsiveness is probably in the client's court. But I thought it was interesting to talk about!