Fork me on GitHub

is there anyway to disable parallel key timeouts? My usecase is that I want a delay computation, but reuse the request cache, so I would like to call p/entity-attr! later. I put a lambda function with that call on a core.async channel to be processed later. If by that time the resolver has run I want to reuse it, otherwise calculate it on the spot, without duplicating the resolvers code. Sadly I get a key process timeout. What could I do differently?


@thenonameguy the parallel timeout is configurable, I'm not sure if you can disable it but you can make it a large enough number so it works, the default is 60s (just for context, this is kind of a last resource failing system, if nothing works this tries to guarantee the user will get some response after that time), you can change the value using environment data, you need to set :com.wsscode.pathom.parser/key-process-timeout 60000 (default value in this example)


about reusing the cache, one trick you can do is also send the cache atom in the env, example: (let [cache (atom {})] (parser {::p/request-cache cache} [...]))


this way you can hold to the cache after the request is done


Thanks! why can’t I just get the existing (default) ::p/request-cache from the env in the mutation I’m firing off this async lambda and pass it back in? It should be a reference type, no need to put it an ‘initial’ atom myself, I think


with the high timeout hack I could progress but p/entity-attr! says that it’s unable to resolve my attr, while the entity has all the necessary inputs to do so


I’ll workaround this for now, I’ll revisit it by tmrw


@thenonameguy its just that you don't have access to the env at the output level, the request cache is created one per request and then thrown away, so altough you can access during in-processing, there is no external access point for it, makes sense?


yes it makes sense, but I’m firing off this async stuff in a mutation, where env is in context


with it the per-request cache AFAIK


so I don’t need to put it in manually


if my assumptions are correct


ah, in this case you can pull it, I'm not sure exactly how you are trying to do it, but by the description it seems correct, one thing to remember is that the case is based on resolvers, so what you cache is not the entity data but the resolver results, knowing that may help you


another thing, p/entity-attr! uses ::p/entity from the environment, so make sure that this data point has the inputs you need


Entity attributes #{:some/response} could not be realized
#:com.wsscode.pathom.core{:entity {:foo true, :java/inet-address #wp/inet ""}, :path [[:java/inet-address #wp/inet ""]], :missing-attributes #{:some/response}}


and :some/response only depends on :java/inet-address


{::pc/input  #{:java/inet-address}
   ::pc/output [:some/response]}


looks ok to me


(pc/defmutation async-maybe-resolve [env params]
    (async/<! (async/timeout 1000))
    (some-side-effect (async/<! (p/entity-attr! env :some/response))))


the gist of what I’m trying to do


oh, imagine a timeout before the take


yeah, looks correct, I never tried from a mutation though, may be a bug, if you can get a minimum repro of the issue I can take a look


ok, it’s getting pretty late here in Budapest, but I’ll try a bit more tmrw and post results 🙂 thanks again for Pathom, it rocks

👍 4

have a good rest

🙏 4