Child command schedule on the same clock

[wli3]

If a command scheduled another command, due to the anonymous clock (used to freeze time). The new command will be created on the anonymous clock and then fallback to default clock.

The solution is passing the origin clock down, called parentclock in the code, and when scheduled new command, try to use it instead.

[jonsequitur]

I think that this approach adds more complexity to an already complex area. The behavior that would make more sense to me is to have the CommandContext.Clock set to the expected clock.

The anonymous clock you're encountering, was it only a test clock or do you see this as well when not using VirtualClock? Maybe the clock lookup should bypass anonymous clocks. Or maybe the anonymous clocks simply need to take the same name as the "parent" clock without having to pass down two different clock references.