Fork me on GitHub

Yes, that popped right out in testing, but it's a day-1 bug.

Lennart Buit17:11:41

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).

Lennart Buit17:11:22

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.


But. don't think this change affected that, it just highlighted it.

Lennart Buit12:11:00

No there was no order guarantee to begin with ^^.

Lennart Buit12:11:13

I'm not sure what is expected tho. For me the argument can fall both ways