Fork me on GitHub

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.


[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"]


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.


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.


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.


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.


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.


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.