----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/71641/#review218316 -----------------------------------------------------------
src/master/master.cpp Lines 7847-7848 (patched) <https://reviews.apache.org/r/71641/#comment305974> This seems to warrant an explanation? Seems very non-obvious how this situation can happen. At a higher level I'm a bit confused about this patch vs the ticket. MESOS-9962 describes a case of a completed executor having non-terminal tasks, but this patch is talking about erasing completed tasks if they clash with non-terminal tasks recovered on an agent. Those are two different scenarios? Did you link in the wrong ticket? - Benjamin Mahler On Oct. 21, 2019, 5:03 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/71641/ > ----------------------------------------------------------- > > (Updated Oct. 21, 2019, 5:03 p.m.) > > > Review request for mesos, Benno Evers, Benjamin Mahler, and Greg Mann. > > > Bugs: MESOS-9962 > https://issues.apache.org/jira/browse/MESOS-9962 > > > Repository: mesos > > > Description > ------- > > Under certain conditions tasks which were previously `TASK_LOST` and > completed can reappear in non-terminal states, e.g., if the agent on > which they where running reconnect. > > This patch adds garbage collection of such completed tasks so that users > do not see tasks twice when obtaining task information from the master > API. This change does not affect tasks status updates where we already > correctly reported a previously `TASK_LOST` state as superseded by e.g., > `TASK_RUNNING`. > > > Diffs > ----- > > src/master/master.cpp 351823e69f14dbb5eb1ea2b108c42e93722f1eff > src/tests/master_tests.cpp 5486e23ce146eda9191e081a48c1f3fcb52a7569 > > > Diff: https://reviews.apache.org/r/71641/diff/1/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
