Implement cancellation contract for async_rpc operations

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Fixed
    • Priority: Major - P3
    • 6.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • Service Arch 2022-12-26, Service Arch 2022-12-12, Service Arch 2023-01-09, Service Arch 2023-01-23, Service Arch 2023-02-06
    • 20
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      We now have a defined cancellation contract that the async_rpc API should implement: 

      The RPC library should append an OperationKey (GUID) to all operations it sends. When those operations are canceled, if networking has begun for that operation (i.e. any data may have been sent), the RPC unconditionally sends fire-and-forget _killOperations for that OperationKey to the same remote node. 

      Since the library currently delegates to TaskExecutor/NetworkInterfaceTL to perform networking, implementing this cancellation contract will first involve cancelling any ongoing network interface operations, if they have begun. This is possible by simply using the cancellation token passed to the network interface, and should happen automatically if the async_rpc API's user cancels the token they passed in. Then, the async_rpc API should inspect the NetworkInterface operation response and see if it succeeded or successfully cancelled; if it succeeded, the async_rpc layer needs to send killOperations itself.

      If the NetworkInterface operation was cancelled successfully, the network interface may or may not have sent the required _killOperations. Here, we should do a short/timeboxed investigation on the best solution - one thing we could do is fix the network interface to always send _killOperations in this case, if that fix is small and simple. If it is not, we could have the async_rpc api always send it, even if it ends up being a duplicate _killOperations. 

            Assignee:
            Amirsaman Memaripour
            Reporter:
            George Wangensteen (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: