Fork me on GitHub
#pathom
<
2019-05-13
>
kszabo18:05:08

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?

wilkerlucio18:05:41

@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)

wilkerlucio18:05:20

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} [...]))

wilkerlucio18:05:28

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

kszabo18:05:59

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

kszabo19:05:12

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

kszabo19:05:32

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

wilkerlucio19:05:32

@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?

kszabo19:05:04

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

kszabo19:05:10

with it the per-request cache AFAIK

kszabo19:05:22

so I don’t need to put it in manually

kszabo19:05:26

if my assumptions are correct

wilkerlucio19:05:03

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

wilkerlucio19:05:59

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

kszabo19:05:03

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

kszabo19:05:32

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

kszabo19:05:49

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

kszabo19:05:58

looks ok to me

kszabo19:05:37

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

kszabo19:05:46

the gist of what I’m trying to do

kszabo19:05:59

oh, imagine a timeout before the take

wilkerlucio19:05:25

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

kszabo19:05:09

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
wilkerlucio19:05:10

have a good rest

🙏 4