You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of async methods where having an overload with a cancelation token may make sense.
This is only appropriate if the cancelation token can flow down to a system API that can actually cancel the operation.
It is generally not appropriate for the data portal, because it is not possible to flow the cancelation token across network boundaries. For example, indicating that someone could "cancel" a client-side data portal operation makes little sense, because maybe we could cancel the http or gprc or rabbitmq request on the client, but there's no way to actually cancel the operation on the server.
The text was updated successfully, but these errors were encountered:
We should evaluate whether we can pass it along for a data portal operation. Yes, we can't transfer the token itself over the wire. But asp.net core for example provides a token which indicates whether the request has been closed/cancelled or not by the client. That token could be propagated on the server side. But I think that should be a different issue with more planning.
I agree that this need more planning, my idea in this issue is just to add a cancellation token on every interface and implementation that uses a timeout, just like I did on the #3800
A second part would be to make the timeout version obsolete and start to propagate the cancellation token around.
The third part should be to remove the timeouts
Yes, I understand that. I only wanted to raise awareness we could implement a proper cancellation mechanism througout the project. But we should move that into another issue.
Back to the part of this issue:
One method would be
There are a number of async methods where having an overload with a cancelation token may make sense.
This is only appropriate if the cancelation token can flow down to a system API that can actually cancel the operation.
It is generally not appropriate for the data portal, because it is not possible to flow the cancelation token across network boundaries. For example, indicating that someone could "cancel" a client-side data portal operation makes little sense, because maybe we could cancel the http or gprc or rabbitmq request on the client, but there's no way to actually cancel the operation on the server.
The text was updated successfully, but these errors were encountered: