thanks for the pointer, notes add: https://github.com/wilkerlucio/pathom#pathom-3 https://blog.wsscode.com/pathom/v2/pathom/2.2.0/introduction.html#_pathom_3

hello, good question, indeed they do create a cycle, but thats not really an issue, because pathom planner can detect the cycle and skip it, the idea of a bidirectional link is that in case you have one of the sides available, it can translate it into the other

and to start from it, it could be some provided information, or getting resolved via some other resolver

makes sense?

Hi @wilkerlucio. If I understand correctly, preventing cycles is important when creating and executing the plan, but it's fine to have cycles in the initial available graph?

“preventing cycles is important”, not sure what you mean there

Pathom has cycle detection, but is it also important to avoid creating cycles when writing resolvers?

cycles will happen naturally, its not something you should require special attention

reducing the number of paths for each attribute is encouraged since its gonna help keep paths clean, making planning / running faster

Ah, so it's perfectly fine to have an a->b resolver and a b->a resolver.

yup, in fact that is exactly what the equivalence resolver is, it makes two alias resolvers, one in each direction

Okay, that simplifies my thinking. I thought it's necessary to pay special attention to make sure that your resolver graph remains a DAG - as in, being careful that you don't define cycles.

no need, the planner will make sure cycles dont happen

and the graph generated by the planner will always be a DAG

tyvm @wilkerlucio, that clears it up for me.