SRP taken to its extreme isn't practical. Let's take a practical, familiar, real-life example where SRP has been successfully implemented: fast food restaurant chains. In SRP, you would define a restaurant in a chain to have a single responsibility of serving food to customers. However, implementation details include things like handling credit card payments, obtaining ingredients, following food safety regulations, etc.
You won't see a bank inside the restaurant, nor a farm just outside to obtain the potatoes, cows, chickens, etc, plus the food to feed the livestock, nor a processing plant to turn those ingredients into their final products. The restaurant has several outside sources it depends on for most of what it needs serve its single responsibility.
It's worth noting that by doing this, a restaurant chain can change, for example, the credit cards it supports, or the style of French fries it serves, simply by modifying the relevant service that all the restaurants in the chain rely on. The individual restaurants largely don't need to know, or care, how those external services work, and are largely not directly impacted by implementation changes made upstream.
Likewise, your QueryHandler needs to log certain data, such as errors. It's reasonable to pass in a Logger to your implementation in order to facilitate this function, just as the restaurant needs a way to handle credit cards. Because of how this code is designed, it only needs to worry about handling queries, and doesn't need to worry about how logging actually happens. A developer can change the Logger to a memory logger, a network logger, or even a blackhole logger (e.g. write to /dev/null), and the QueryHandler doesn't need to know that anything changed. It's handling its single responsibility.
In a practical implementation of SRP, you need to think about what the actual steps are in order to fulfill a responsibility. You can't reasonably implement logging inside QueryHandler, because then you'd have a fixed implementation here, and presumably every other class that needs logging, which would be a nightmare if you ever needed to change how logging operates.
The Logger's responsibility is to provide a simple logging API, and the QueryHandler's responsibility is to use that Logger to log errors in the course of handling queries. Even though QueryHandler is doing two "things" at a technical level, it is handling just one responsibility, and that is to reliably service queries. That reliability needs a Logger, so that makes it part of QueryHandler's responsibility. A class may do many "things" internally, but from an external point of view, it should appear to do just one thing (or, perhaps, more accurately, one set of related things). Everything tangential to that responsibility should be in another class.
My only real objection with your code is that the caller needs to provide a Logger instance. It'd be better if your QueryHandler used a global Logger instance, or perhaps used inheritance or a mixin or something. I feel like the caller shouldn't need to provide a Logger, because now you've got to pass the Logger from layer to layer, making logging everyone's responsibility. However, directly speaking to "should QueryHandler log errors," it definitely falls within the scope of QueryHandler's role in SRP, much like credit card processing is in a restaurant's responsibility of serving customers food.