Error handling in Query trait implementations

[johnbcodes]

It doesn't come up in the Query documentation but in GenericQuery#use_error_handler it states:

Queries are infallible and should never cause errors, but programming errors or other technical problems might.

However, in the Query docs it states:

Some example of tasks that queries commonly provide:

• update materialized views
• publish events to messaging service
• trigger a command on another aggregate

These are all things that are usually very fallible which is why GenericQuery#use_error_handler and the caveat but programming errors or other technical problems might exists.

What I don't understand is why Queries should be infallible and why they would not be "bubbled up" using Result in an idiomatic way. My thinking is that in such a scenario I would like to inform the end-user. I think it's reasonable to assume that should any Query fail it's likely the application is in an above-average bad state data-wise. Enough so that user expectations around this particular error situation could be enhanced/managed. It would probably require an additional AggredateError variant to differentiate during error handling.

A workaround is to panic and use something like tower-http's catch_panic and string matching of the message but this goes against idiomatic Rust's preference of not using panics for error handling and seems more obfuscated code-wise than creating a specific layer/handler.

[davegarred]

Hi @johnbcodes.

The reason that queries are infallible in the framework is that in CQRS the command handler work on the aggregate is always considered the sole source of truth. Any logic that could cause the command to fail should be inside the aggregate. Without that separation of aggregate logic and query updates we would lose a lot of the benefits that CQRS provides us (API decoupling, horizontal scaling, state error debugging, etc.).

Application of events to queries can absolutely fail IRL. In CQRS though you need to find other ways to deal with it. Many times this will be putting the view in question into some sort of an error state (e.g., add a flag to show the customer that "something is wrong, please call customer service...").

These individual failure cases must be dealt with as you would in an event processing system rather than in a more common webapp style application.