Hi.
I’m having an issue with async resolving. How can I properly handle a case where response delivery fails?
-> (deliver! promise response) throws an error due to invalid response data (currently, during development, I have a field containing a lazy seq with an unresolved error 🙈)
-> the next call (deliver! promise nil error) does nothing
-> the client receives a timeout, and it looks like there’s an open thread left
What is the correct way to handle this?
This promise is already resolved:smiling_face_with_tear:
So first deliver! call throws an error, second deliver! call is impossible because promise is already delivered.
You might get a better answer on the general #clojure channel but it seems to me the laziness might not be serving any purpose here. In the short run, if error avoidance is paramount over efficiency, you can try to force realization of the sequence before delivering it, with (pr-str ...) (then just discard the string). But to avoid such problems in future, whatever is generating the structure that will be delivered should do it without laziness.
For me this is not really a question about lazy sequences.
It is a question about the possibility of a deliver! failure that leaves no recovery path.
If deliver! can throw after the promise is considered delivered, then from the caller’s perspective the async contract is broken: you can neither retry nor reliably signal an error.
I was initially trying to understand whether there is a principled way to programmatically avoid such failure, rather than relying on additional discipline at development time (e.g. “never pass lazy data”).
After realizing that the promise is already considered delivered in this case, I’m curious to hear feedback from the Lacinia dev team. Is this something broken on my side, or an actual unpleasant edge case in the async delivery model? (My Lacinia version is 1.2.1.)
At the scale of a library like Lacinia, and in real-world development processes, if such a failure is possible, it is effectively inevitable.
Especially if it can lead to requests/threads that never complete.