This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # beginners (22)
- # braveandtrue (6)
- # calva (2)
- # cider (85)
- # cljdoc (1)
- # cljs-dev (21)
- # cljsrn (2)
- # clojure (70)
- # clojure-italy (9)
- # clojure-spec (1)
- # clojure-uk (144)
- # clojure-ukraine (6)
- # clojurescript (109)
- # cursive (59)
- # data-science (15)
- # datomic (40)
- # emacs (8)
- # fulcro (64)
- # funcool (8)
- # graphql (8)
- # hispano (3)
- # hoplon (7)
- # jobs-discuss (29)
- # leiningen (3)
- # luminus (2)
- # off-topic (13)
- # onyx (9)
- # parinfer (49)
- # pedestal (2)
- # portkey (8)
- # re-frame (10)
- # reagent (33)
- # reitit (13)
- # ring (2)
- # ring-swagger (16)
- # shadow-cljs (193)
- # spacemacs (1)
- # sql (19)
- # tools-deps (19)
As discussed some days ago (https://clojurians.slack.com/archives/C06GSN6R2/p1534530179000100) ('m using Muuntaja 0.6.0-alpha3). However it's caused some unit tests break. I'm here to ask if it's a bug or a feature, since I know nothing of msgpack standards. Basically the unit test that is breaking does a
[clojure-msgpack 1.2.1] on the response from the compojure-api app, and the returned data is no longer compatible. It results in a
java.lang.ClassCastException: java.lang.Byte cannot be cast to [B. So what the new msgpack code packing isn't what the old client msgpack code wants to see. I don't know if there's a standard that's supposed to ensure the format of the data doesn't change, but I'm hesitant to go changing client code to use a new msgpack tool when the old one has worked all this time.
time to read up on msgpack I guess, but could use some advice on whether this is a new alpha muuntaja bug, or whether I really should be upgrading the msgpack client.
My impression is that my client msgpack (unpack) code shouldn't be breaking, but perhaps the argument can be made that
msgpack.core is old and broken and so it's time to upgrade.
Hmmm, 1.2.1 is the latest and greates of
msgpack.core. Of course this may not be a msgpack issue at all, it could be the muuntaja and compojure-api alpha-23 upgrade have ... altered ... the encoding of what is returned by the route.
The route in question declares a prismatic schema return type of
(s/defschema DocumentLayout (sweet/describe (s/pred bytes?) "Protocol buffer binary encoded data."))
The only change in the broken APIs is the upgrade to compojure-api alpha23 and muuntaja 0.6.0-alpha3, and elimination of this line from the api format options:
Since that msgpack-format support is no longer present. I didn't see the need to declare any formats because the current defaults are supposed to include msgpack. Or do I need something afterall?
- :formats (m/create (-> m/default-options (msgpack-format/with-msgpack-format)))
Will re-examine the defaults, could have sworn current muuntaja said msgpack was a default supported format.
Did the obsoleted
with-msgpack-format support "application/msgpack" where the new msgpack defaults do not?
@dave.tenny the muuntaja CHANGELOG describes the changes with msgpack: https://github.com/metosin/muuntaja/blob/master/CHANGELOG.md#060-alpha1
The problem is not anything about the request body, the problem is the client breaks decoding the HTTP response from the compojure-api app
So it's asking for "application/msgpack" as the "accept" header, which worked before, but now results in unpacking exceptions, perhaps because the server response isn't being encoded the way it was before.
We had no special code to support that header,
with-msgpack-format and the old muuntaja seems like it must have been supporting it before but not now.
I'm not sure which other parts of the breaking changes in changelog might apply here, unless it's a need to set the Content-Type where we weren't before, re:
**BREAKING**: if a "Content-Type" header is set in a response, the body will not be encoded, unless `:muuntaja/encode` is set