@tolitius i'm getting multiple order instances in my yurt blueprint... do you know why this could happen?
like so: https://gist.github.com/bsima/09995cb9e5f18b7b87f425b8e9e2e513#file-repl-clj-L10-L11
@bsima: you mean order X
and order X
for different states?
that's interesting
yeah, multiple {:order 1}
...
did you change esclient
and config
declarations in the same repl session?
can you do:
(require '[mount.tools.graph :as graph])
(graph/states-with-deps)
and paste results here?I don't think so, pretty sure it's this way on startup
yeah one sec
mem> (states-with-deps)
({:name "#'datastream.core.conf/config", :order 1, :status #{:stopped}, :deps #{}}
{:name "#'datastream.core.search/esclient", :order 1, :status #{:stopped}, :deps #{}}
{:name "#'datastream.core.persist/persister", :order 2, :status #{:stopped}, :deps #{}}
{:name "#'datastream.service.api/server", :order 2, :status #{:stopped}, :deps #{}}
{:name "#'datastream.core.topics/client", :order 3, :status #{:stopped}, :deps #{}}
{:name "#'datastream.transactor.core/transactor", :order 4, :status #{:stopped}, :deps #{}}
that's from a fresh repl
i know the specific order discrepancy: topics/client
should start before api/server
. If i do that manually with calls to (mount/start ...)
then it's fine
but I can't find where this discrepancy comes from 😕
@bsima: hmm.. would you happen to have a link to a sample repo that reproduces this? this could be something simple, or a possible bug.. (does not seem to be isolated to yurt
though)
unfortunately the repo I'm working on is proprietary... but I'll keep looking for the root cause and let you know here if I find a minimal reproducible example
great, thanks. I'll ping you if "it comes to me" first 🙂