Clojurians Log v2

> for observability purposes, you may want to ignore those cases Right, but I also need some way of running it when the batch resolver finally runs. Is this possible? > honeycomb looks nice It is! Highly recommended.

Oh dear, and the result is a map with ::pcr/batch-hold on it. By then it is far too late to decide not to run Honeycomb. Honeycomb must be running while the resolver is evaluating… Do you see? It can't wait until after the resolver has run to evaluate the performance. In that case I'd have to run each resolver twice: first once, to detect whether it is a batch, then again to actually measure it.

I need either a way to determine ahead of time that it is a batch resolver, AND a way to run a plugin when the batch is actually executed, or (and this would be the vastly preferred case) I need an extension point that works the same way for batching and non-batching resolvers: i.e., it that runs on the actual execution of the resolvers, regardless of kind, and not on any preparatory step.

The first case would make it work, but it would also required two separate plugins to handle the one use case. The second case would make it work, and only require the one extension point.

Hey we have a prod service using Pathom2 and started to see some weird behavior for some queries. After reducing the query’s scope to two attributes we can see errors like this:

"Assert failed: Tried to remove node that still contains references pointing to it. Move\n      the run-next references from the pointer nodes before removing it.\n(if after-nodes (every? (fn* [p1__41590#] (not= node-id (-> (get-node graph p1__41590#) :com.wsscode.pathom.connect.planner/run-next))) after-nodes) true)"

Interestingly changing the order of the two problematic attributes in the query fixes the problem. Still we would like to understand the issue and potentially fix it

hello Janos, from the error message I assume you are using reader3?

That's correct. Back when this service was implemented, there were performance tests done and based on the results the team went with async-parser + reader3

that reader is experimental in pathom 2, the planner there is stopped, if porting to reader2 makes performance too bad, them maybe better to try to use Pathom 3 (which uses a much more evolved version of the algorithm used in reader3 on Pathom 2)

Is it pathom 3 already in a shape you would recommend using it in prod?

I would be happy to migrate to that just didn't know that it's already has all the features pathom2 had

I mean, reader3 is as risk as it, there may be some internal breakages in pathom3, but the external api is mostly stable, the prod stable still is the reader2 on Pathom 2, but between reader3 and pathom 3, pathom 3 has a better algorithm, because its an evolution of reader3 (which wont be getting any updates)