Fork me on GitHub

Hi đŸ‘‹ From the pathom3 docs I see > Mutations are the first thing the runner executes, this way you know the reads from the query will have update values, in case the mutation affects something related to them. Is this statement still true with ::p.a.eql/parallel? true


yes, but with some caveats 1. if a mutation is async, other mutations may run at the same time 2. mutation sub-queries will run before the main query part (that's also true for other runner modes) other than that, the read part should only run after the mutations are done


Perfect! That’s what I was hoping for but wanted to confirm. Thanks!


Hi, I was just checking my code with strict and lenient mode, and I found something strange: in Lenient mode, sometimes an attribute will resolve (and in strict, it'll throw - always). Looking at the graph, it seems that the bug is on my side, but this opens a question: does lenient mode "tries hard" to fulfill the attribute? Or it's an implementation detail that may go away in the future?


this is more related to cases where output descriptions are missing, for those cases lenient may get a result where strict does not


@U066U8JQJ what do you mean output descriptions missing? You mean when the resolver does not declare that it'll output a key, and it does output it anyway?


Ok, that's not what's happening. What is happening is that I have multiple resolvers for :text/contents. For example, :text/current-var can return {:text/contents "foobar" :text/range [[0 1] [0 7]]}. There's also a resolver for :text/top-block. This resolver expects :text/contents and :text/range to get the "top block" of that content in that specific selection. So, suppose that I ask for {:text/current-var [:text/top-block]}. This should not resolve - :text/contents will always be a var, and :text/range will not be pointing to a block. The issue is that, on strict mode, this works as expected - it returns an error. But on lenient mode, it somehow resolves. I tried to debug it, and found that it indeed found an error in the top-block resolver, then it tried with different :text/contents that have lower priority. Is this expected?


hard to understand from text, can you make a repro demonstrating it?