immutant 2018-08-27 | Slack Archive

jdt11:08:00

Hello all. I'm getting a strange behavior when attempt to call immutant.web.async/send! with a string in the :on-open handler for the channel. It works fine in the first channel I open in the HTTP service, but when I close that channel and try to do the same thing with a second channel, I get get the following strange down-stack behavior where someone is trying to pass a keyword where a string was expected, and I know it isn't me. In fact I even have a test for string? before calling the send! function. Just curious if anybody else has seen this.

jdt11:08:11

jdt11:08:56

[io.undertow/undertow-core "1.4.18.Final"]
   [io.undertow/undertow-servlet "1.4.18.Final"]
   [io.undertow/undertow-websockets-jsr "1.4.18.Final"]
[org.immutant/web "2.1.9"]

jdt12:08:38

It's unclear to me how the io.undertow stuff plays, if at all, I mention it because it's in the parent project dependencies. All I'm doing here is an immutant.web/run on the app with the sse service.

jdt12:08:29

Actually it's this line and its call to the headers logic that's blowing up, and nothing to do with what I'm passing to the send! call. https://github.com/immutant/immutant/blob/master/web/src/immutant/web/async.clj#L88

jdt12:08:23

It's expecting string keys in the headers map, and didn't get one. I have no idea where the headers are coming from in this case or what I've done to cause the problem. https://github.com/immutant/immutant/blob/master/web/src/immutant/web/internal/headers.clj#L46

jdt14:08:07

Okay, problem solved I guess, though I don't understand the nuances. This was happening when I tried to add some additional headers in the server SSE response from as-channel. I would have expected those headers to go to the client and that would be the end of it. So to recap: 1. Server returns an as-channel result to which we assoc some additional headers. 2. Later, the :on-open is executed and attempts to do an async send! 3. Runs afoul of logic that didn't like keywords that were assoced to the as-channel result (keywords, because we expected compojure-api to give them to the caller in appropreate format and never expected to see them again.

jdt14:08:42

Anyway, I'll just suppress the additional headers for now, but I'm curious why adding headers to the as-channel response would cause the problem noted above.

jdt14:08:26

Side question, when, exactly, is :on-open called for SSE channels? Just curious since my client was aborting before the clj-http get retrurned due to the server side exceptions from the send! logic in :on-open.

2018-08-27

Channels