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

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

@tolitius ^

great, thanks. I'll ping you if "it comes to me" first 🙂