This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-19
Channels
- # announcements (3)
- # asami (3)
- # babashka (39)
- # beginners (65)
- # calva (13)
- # cider (4)
- # clj-kondo (69)
- # cljdoc (19)
- # cljs-dev (2)
- # clojure (90)
- # clojure-dev (10)
- # clojure-europe (61)
- # clojure-france (15)
- # clojure-nl (8)
- # clojure-uk (2)
- # clojurescript (28)
- # conjure (2)
- # core-logic (4)
- # cursive (8)
- # datalevin (5)
- # datascript (7)
- # datomic (14)
- # depstar (4)
- # events (1)
- # graphql (7)
- # holy-lambda (5)
- # jobs (5)
- # kaocha (1)
- # malli (14)
- # membrane-term (13)
- # missionary (13)
- # nextjournal (6)
- # off-topic (1)
- # polylith (15)
- # portal (10)
- # re-frame (35)
- # reitit (1)
- # remote-jobs (3)
- # schema (3)
- # sci (121)
- # spacemacs (6)
- # tools-build (8)
- # tools-deps (74)
- # xtdb (7)
I think I noticed this bug before too. We had it fixed in our own lacinia-pedestal subscription interceptor. Not sure if relevant, but your fix doesn’t have a ordering guarantee: If you call source-stream three times in a row, but the nested selections have wildly different performances, then messages may reorder on the websocket (so, not in the order you called source-stream).
This is a trade-off tho, your solution allows for higher throughput
I don't think this change affected any ordering issues though? If you pass A that take 100ms then B that takes 10ms, I'm pretty sure B will be sent to client before A. This is a feature, but may not be ideal. It will take a bit more book-keeping to ensure that output order matches input order.
No there was no order guarantee to begin with ^^.
I'm not sure what is expected tho. For me the argument can fall both ways