Can you explain how this helps in a little more detail? I'm trying to keep stuff that isn't already public non-public unless there's a good reason not to. It sounds like this might be one, but why not (for example) have a variable name that makes it clearer what query this is tied to rather than exposing this property publicly?

I think any solution is fine that allows someone to access the query after they have created the watcher.

My exact use case is we have a paginated list of images and a watcher for each query. The query has a list of images and a total number of images. When a user deletes a photo we need a way to update those totals on each query in cache, which AFAIK can only accessed by the query.
Because we are already keeping the watchers, we iterate over those and use the queries to update the cache.

for watcher in paginatedViewModel.watches {
            apollo.store.withinReadWriteTransaction({ transaction in
                do {
                    try transaction.update(query: watcher.query) { (data: inout T.Data) in
                        if var poiMedia = data as? PoiMediaListQuery.Data {
                            poiMedia.poiMediaList?.totalCount -= 1
                            // This was just T.data it is safe to cast it back
                            // swiftlint:disable:next force_cast
                            data = poiMedia as! T.Data
                        }
                    }
                } catch let error {
                    AppLogger.debug("Failed to update paginated image cache: \(error)")
                }
            })
        }

We theoretically could keep the queries around as well, but it seems to make sense to me that because the user has to create the watcher with the query that exposing it isn't a big deal.

OK and it seems like you can't just swap the poiMedia.poiMediaList?.totalCount for just getting count since that's probably going to contain some unloaded data and totalCount could be way way more than count.

I'll probably go ahead and approve this one since there's nothing on Query that can be modified so the potential for damage isn't totally awful, but this sure seems like a super-roundabout way of updating this information.

I would recommend talking to your backend team about having some kind of mutation that would alter the poiMediaList and hand info about it back, so that you could have that handle updating the totalCount rather than having to do it manually.