async_rpc util getAllResponsesOrFirstErrorWithCancellation can leave dangling continuations

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Service Arch
    • Fully Compatible
    • ALL
    • Service Arch 2023-07-10, Service Arch 2023-07-24, Service Arch 2023-08-07
    • 112
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      In getAllResponsesOrFirstErrorWithCancellation , we accept a vector of futures and a cancellation token. We return a future that is resolved once all the input-futures resolve with success, or one resolves with an error.

       

      When any of the input futures resolve with an error, we use the cancellation token to cancel the work that produces results for the other futures. However, instead of waiting for this cancellation to "take", and ensuring all input futures resolve (which they should promptly after the cancellation), we short-circuit and ready the output future with a Cancelled status. This means that, when the future returned by the function is readied, there still may be code scheduled to run to produce results for the input-futures that hasn't observed the cancellation yet. If that code captures references to variables whose lifetime is guaranteed only while the result-future of getAllResponsesOrFirstErrorWithCancellation is not yet readied, it could read dead/destroyed objects.

       

      The safe contract for this function should be: "once the output future is resolved, all input futures have resolved, with either cancellation/error or success", which would resolve the lifetime issue. 

            Assignee:
            Alex Li
            Reporter:
            George Wangensteen (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: