I understand where this is coming from: Technically, all units still on the adventure map's star menu automatically get returned to their owner's star menu with a delay of X (15, 30, 90 minutes) depending on the unit type once the adventure ends.
A "travelling general" that is just dismantling their garrison is technically still on the adventure map and therefore affected by the logic.
Easy solution: DO NOT end the adventure before all generals disappeared out of the adventure's star menu.
BB could implement this kind of logic as well: Adventures don't end if there are generals which still have instructions. But I doubt you'd want that fix, because it would force you to wait for all generals to return to their garrison before you could end, adding a good 5 minutes to Fairytale adventures and breaking the current RBN strategy.
The more complicated solution would be to calculate the remaining dismantling time, then add that to travel time, then send all generals in the process of dismantling to their target, then end the adventure.
With Aspect-Oriented Programming, that would be a small issue. However, given what I've seen from BB so far, they do not seem to utilize AOP (it's a rather hard performance hitter as well) and to program this imperatively or into object modelling has high risks of producing side effects.
Without blaming BB for sloppy coding or anything:
Would you rather WAIT 1 minute for your generals to travel over before ending the adventure - or risk the entire adventure mechanism becoming broken for weeks, maybe months?
... just tell your lootspotters "Don't end. I will!"