At this point, the need is to clean up the DAGScheduler's data structures that reference the removed stage.  If you are 100% certain that the stage's notion of shuffleDeps contains every shuffleId that shuffleToMapStage is tracking for the stage, then you can take the simpler route that you have of working from the stage's understanding.  I wasn't 100% certain of that (which is not the same thing as saying that I have a good reason to believe that the stage's understanding of shuffleDeps will diverge from shuffleToMapStage's understanding), so I took the safer route of working from what shuffleToMapStage's knows instead of from what the stage knows.