This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-25
Channels
- # babashka (108)
- # beginners (40)
- # calva (78)
- # clj-kondo (4)
- # cljs-dev (2)
- # clojure (26)
- # clojure-dev (1)
- # clojure-europe (1)
- # clojurescript (53)
- # conjure (16)
- # cursive (7)
- # data-oriented-programming (2)
- # datomic (11)
- # emacs (1)
- # fulcro (45)
- # leiningen (22)
- # lsp (30)
- # meander (9)
- # off-topic (14)
- # polylith (13)
- # proletarian (1)
- # reagent (1)
- # reitit (8)
- # releases (1)
- # reveal (4)
- # rewrite-clj (2)
- # sci (12)
- # shadow-cljs (3)
- # sql (2)
- # vrac (1)
In addition to the job handler being passed in, I think the retry-strategy could also be a function. I had an idea to derive the retry information from the exception, e.g. look at common retry headers from HTTP in the ex-data, or look for cognitect anomalies and how they might impact whether to retry again or not.
Something that did fall out of reducing the retry-strategy & job-handler to passed-in functions is that it made the job-type redundant as far as I can tell. This means the notion of a job type can move into the payload in "user space", rather than being baked into the library.
From a little hacking these changes seem fairly trivial as it's just making arguments out the handle-job! and retry-strategy functions and passing them to the appropriate places. I think you could retain the existing system by having the enqueue mechanism automatically add a ::job-type
key to the payload and use that as the dispatch into the existing multi-methods. I suggest that there's naming updates to move that into some kind of flavour.