Clojurians Log v2

Hey! You just need to wrap it in a function: :schedule (fn [] (iterate #(biff/add-seconds % 60) (java.util.Date.))). That way the use-chime component can get the schedule starting at the time the system starts up instead of at the time the namespace with your module is required.

Makes sense. I copied & pasted from here. Will correct + send PR if that's useful. https://github.com/jacobobryant/biff/blob/master/src/com/biffweb.clj#L976

ah yes that should be updated. I can go ahead and fix that.

thanks for the catch!

thumbsup_all

(Responding to your deleted message, maybe you figured it out already) In that case I wouldn't use scheduled tasks at all. Instead you can create a custom component:

(defn use-something [ctx]
  ;;; your code here
  ctx)

(def components
  [...
   biff/use-chime
   biff/use-beholder
   use-something])

Yeah, i was trying to debug something with the module I'm working on and this was my last resort. I'll write it up in a separate thread.

I think I see the problem actually! From your stacktrace I see it's the jwks-keys function that's failing, i.e. oidc-get-well-known-config must be returning successfully. And your /auth/config handler only calls the latter function, not jwks-keys. So maybe there's a bug there.

of course if it works locally, that makes things more interesting. But perhaps in the docker compose environment, the return value of oidc-get-well-know-config is different than it is locally for some reason?

in any case, I'd definitely add :debug true to the jwks-keys function and call that in the /auth/config endpoint to compare

OMG 😮

You're right

Thank you so much! Thing about working alone is sometimes you go down the wrong path and all sense abandons you. It works on local because the well-known endpoint returns localhost. I forgot to change that to "keycloak". Also momentarily forgot there was a second http request there at all somehow.

haha great to hear! I know the feeling. There's a class of bugs where they're so hard to find because they're simple enough that they slip past your defenses... I spent 6 hours once fighting some problem that ultimately was caused because I was passing an Integer somewhere instead of an int or something like that

@taylor.jeremydavid @jarohen finally got something put together with the secondary-indices API!

Always a pleasure following your work on Biff.

I just created a new project, excluded the xtdb libs, created the uberjar, and the rocksdb files were successfully excluded from the uberjar. Perhaps run clj -Stree and double check that the xtdb libs aren't in there? I have the following in my deps.edn :

:deps {com.biffweb/biff                    {:git/url "", :git/sha "c50311e", :git/tag "v1.8.13"
                                             :exclusions [com.xtdb/xtdb-core
                                                          com.xtdb/xtdb-jdbc
                                                          com.xtdb/xtdb-rocksdb]}
        ;; Provides xtdb.api functions that com.biffweb depends on, all of which throw UnsupportedOperationException
        com.biffweb/xtdb-mock               {:git/url "", :git/sha "c50311e", :git/tag "v1.8.13"
                                             :deps/root "libs/xtdb-mock"}

$ jar tf target/jar/app.jar  | grep rocksdb
librocksdbjni-osx-x86_64.jnilib
librocksdbjni-linux64.so
...

Oh, the missing xtdb-mock, everything is normal after it’s added in the deps.edn. When I followed the instructions in “how to use Postgres with biff”, I noticed the xtdb-mock in step 7,but I thought it’s not a necessary dependency so I didn’t added it to my deps.edn.

hm, I would have expected that to work. Just to confirm, if you delete the uberjar and then generate it again, it still has the rocksdb files in it? if so I'll try reproducing this tomorrow.

Yes, delete then regenerate, and rocksdb files still appear.

interesting--adding xtdb-mock shouldn't prevent any rocksdb files from getting into the uberjar; it just makes it so that if you add the xtdb libs to your :exclusions, you won't get an exception when biff code tries to do (require 'xtdb.api) etc. e.g. when I tried running clj -M:dev uberjar without xtdb-mock, the uberjar doesn't even build; I just get an exception. but, as long as it's working now, I guess we're all good!