[SERVER-79072] Change the semantics for or ban ExecutureFuture::getAsync Created: 18/Jul/23  Updated: 07/Dec/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: George Wangensteen Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Service Arch
Operating System: ALL
Sprint: Service Arch Prioritized List
Participants:

 Description   

As this test case demonstrates, callbacks chained via ExecutureFuture::getAsync do not run when the executor rejects work / is shutdown. While this matches the semantics for ExecutorFuture::then / ExecutorFuture::onError, it obviously does not parallel the semantics for the other method of terminating a continuation chain, ExecutorFuture::get. The two cases aren't exactly parallel, because get requires another thread to block and receive the result of the continuation chain. However, terminating a continuation chain with getAsync and then allowing that getAsync to never run means that errors from earlier in the chain may never be handled/addressed and are silently ignored. Logically, I don't think it makes sense to allow chains to terminate with unhandled results in the common case. 

 

This has also bit us practically several times: SERVER-54735,  BF-20215 , BF-20298 , SERVER-71662 , SERVER-79070 all arise from this issue. 

 

I propose that we either: 

  • Ban ExecutorFuture::getAsync and remove existing use-cases, rewriting them to use onCompletion and somewhere requiring a blocking get
  • Modify the semantics so that the code in getAsync always runs, even in the case of shutdown, but will possibly run inline in the case the executor rejects work. This is how we end up fixing the issue practically outside of the future-library today, via unsafeToInlineFuture, but the implications of doing so inside the library are greater. 

Generated at Thu Feb 08 06:40:00 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.