Clojurians Log v2

I suppose it's going to be way too hard to move away from antlr in order to support cljs?

oh hi there! I had a pleasant experience integrating lacinia into my web service at work. There is one thing that bothered me though: why does documentation suggest to keep schema as edn file and than walk it with attach-resolvers to update resolvers? I just defined everything in code with resolver functions right in the schema — I think that’s simple and makes total sense…

Not sure, how do you make sure your not accidentally change the schema?

Because it's an immutable value? And code is under version control? Not sure I understand your question.

It's what works for us, with a fairly large schema. But it's all just data, so you can do what you want ... mix it up, a little EDN, a little GraphQL schema language, a bit of data manipulation, inject some documentation ... you get to decide.

Hey, we are using lacinia.pedestal here, and the other day I was adding an interceptor that sends errors to rollbar to our pedestal stack. One thing I noticed while implementing is that exceptions thrown in lacinia resolvers are catched as of 0.36.0, and passed as values into lacinia.pedestal. The query executor in lacinia.pedestal then consumes this exception before it reaches any of the error interceptors. Is that something you are perhaps open to change. I am open to create an issue, and also to do the work after discussions ^^.

Exceptions are catched (in lacinia) here: https://github.com/walmartlabs/lacinia/blob/c922c7b0bfd405f0fec3a92df32701d0d4903aae/src/com/walmartlabs/lacinia/executor.clj#L480-L481

And logged and consumed (in lacinia.pedestal) here: https://github.com/walmartlabs/lacinia-pedestal/blob/34434816cbc3ac868b7522901a5f0e875c4916cb/src/com/walmartlabs/lacinia/pedestal.clj#L321-L325

This change was related to allowing the query execution to execute on a pooled thread, with a timeout.

So you could look into replacing the interceptor supplied by Lacinia here.

You’d say replace the query-executor interceptor, then. In my code

I was thinking, which is why I am asking. that it may also be possible to split the query-executor in lp in two, one that executes the query and possibly raises and one that applies the result to the context. That way consumers of lp only have to replace this ‘apply query to context’ interceptor, or otherwise, can put an error handling interceptor in between. But I am probably missing something here

No, I think you're on to something, but I'm too busy with urgent work to dive into the code right now.

But the point of inject is to make it possible to amend or substitute interceptors in the default chain easily, even if the composition of the default chain changes between l-p releases.

Thats cool, urgent work is more important! If you want, I can also file an issue to keep track