[SERVER-71573] Ability to terminate early the workflow of a DDL Coordinator Created: 23/Nov/22 Updated: 01/Dec/22 Resolved: 01/Dec/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Antonio Fuschetto | Assignee: | Antonio Fuschetto |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Sharding EMEA 2022-12-12 |
| Participants: |
| Description |
|
The Sharding DDL Coordinator should support is the ability to gracefully terminate the workflow of a coordinator without running all the subsequent phases. The typical use case can be described as:
Today there are several solutions to implement this use case, however it would be useful that the infrastructure of the Sharding DDL Coordinator offers a facility to support the case in a standard way. Ideally, it could sufficient to set a control flag (e.g, _completeWorkflow = true) to gracefully terminate the current workflow before completing the current phase. If a good solution already exists using the current API, describe it on this ticket. |
| Comments |
| Comment by Antonio Fuschetto [ 01/Dec/22 ] | |||||||||||||||||
|
I had an internal discussion with tommaso.tocci@mongodb.com and jordi.serra-torrens@mongodb.com about the use cased described above, and we evaluated two possible solutions that don't require changes to the current infrastructure. Solution 1: Return a dedicated error codeIt consists of returning a specific error code (e.g., ErrorCodes::RequestAlreadyFulfilled) to successfully terminate the workflow, so that the error handler (that is, onError) handles it by simply returning Status::OK(). This solution has already been used in another context however it suffers from a potential problem: if the dedicated error code were returned by any functions used by the coordinator (e.g. as a command response), it would cause the workflow to exit successfully. Solution 2: Fork the future chainIt consists of splitting the workflow based on a condition in two subchains, one of which is literally empty (representing the early termination). Since, based on the current public AP,I this is considered the preferred solution, it follows a snipped that can be used as a reference for the future.
|