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)

I see, thanks for the info, we'll check using reader2 would solve the problem as a quick fix, if not then we could migrate to pathom3 (which we planned to do anyway)