in other words,

(defmethod ig/halt-key! :duct.database.sql/hikaricp [_ {:keys [spec]}]
  (when spec ;; <- !!
    (let [ds (unwrap-logger (:datasource spec))]
      (hikari-cp/close-datasource ds))))

Hey. I personally found hikarycp not very usefull. especially older versions. We switched to use the c3p0 library https://github.com/swaldman/c3p0 and it works fine with Duct

something like this

(defmethod ig/init-key :app.db/c3p0 [_ {:keys [jdbc-url]}]
  (let [datasource-options (merge default-datasource-options
                                  {:connection-uri jdbc-url})
        datasource         (c3p0/make-datasource-spec datasource-options)]
    (sql/->Boundary
     (update datasource :datasource
             (fn [ds]
               (wrap-logger ds))))))


(defmethod ig/halt-key! :app.db/c3p0 [_ {:keys [spec]}]
  (unwrap-logger (:datasource spec))
  (.close spec))

Sure, I have no doubt there's better connection poolin tools around. But my (perhaps poorly worded) question was really about the signature of ig/halt-key!; should your function make assumptions whether spec can be nil or not

I think yes, it should.

If a component raises an exception while being initiated, it isn't included in the system and therefore shouldn't be halted, so I'm a little confused at what's going on in this case. Is HikariCP starting, something else failing, and that fail somehow causes HikariCP to fail as well?

that's a good question. What originally happened was I accidentally started the app without starting a local dockerized db. It took me a few moments to realize this because the first symptom of anything going wrong was a NPE from a completely unrelated component running the halt-key! method that somehow destructured a nil value from the second argument (similar to the spec in the above c3p0 code example). Okay, so I added a (when whatever ... to that component and of course now the NPE was thrown from yet another component (the duct hikari component in this case). At this point I got rather confused as usually when I encounter startup problems with integrant I get that "error on key foo when starting system" -style exception and started to wonder if this is some feature of duct (of which I know very little) or is there something wrong with our app setup. Of course, at the end of the day this is a rather trivial matter, but I'd sure like to know what's going on 🙂 I think I'll just need to produce a minimal repro of this if I can.

I think the problem has something to do with mixing a rather old 0.6.2 duct (and integrant) with a newer 0.3.1 integrant-repl. At least sometimes I could get a scenario where the halt-key! method was called for not-yet-initialized components with a nil value. Perhaps this is the same thing as https://github.com/weavejester/integrant/issues/40