Issuing query from aggregate or saga

Is this an anti-pattern? The desired effect is to respond to a deadline by issuing commands or applying events that contain data that may have been updated during the interim. In an aggregate this would be performed in a command handler, while in a saga it would be performed in an event handler. The data could be an axon-driven view, or some other outside I/O. It seems reasonable enough, but I am not certain of the implications on task management and unit-of-work.

Thanks,
Joel

Issuing queries from a Saga is quite common. Issuing them from an Aggregate less so. In general, it is good practice to ensure the aggregate contains enough information to handle the command on its own. This improves performance.
If the aggregate simply doesn’t own a specific piece of information, you’ll have to do a query. In that case, you don’t always want this to be “location transparent”. You just want that information to be available “here and now”. This effectively is information that is part of your command model. Use events to build it, but keep it close (conceptually and physically) to your aggregates. They can then consult this information directly when needed.

Hope this makes sense.
Cheers,