[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:
I propose that we either:
|