Excellent questions, and impressive analysis of the code
Question 1
All pending requests should instantly complete with a system.disconnect
error code if the WebSocket connection is disconnected. Admittedly, neither the C# library, nor the Javascript does this! I need to fix that! Thanks for pointing it out!
But yes, a response should be guaranteed, usually within the default timeout duration of 3 seconds. However, a response may exceed this timeout duration by having the service extend it, or if the response contains nested data/resources that requires more time to fetch.
Question 2
The protocol currently does not support transitioning of resources into different types, including transitioning an error to a model/collection, or the other way around.
This is usually a non-issue, but the most common case when it can cause trouble is during service restarts. The scenario could looke like this:
- Service A shuts down for restart
- Client fetches collection from service B. Collection contains references to resources on service A.
- Resgate fetches collection from B, but when following references to service A, it gets no response and generates
notFound
errors. - Resgate returns collection to client, including
notFound
errors. - Service A is restarted.
In the above steps, the client would end up with errored resources, and would need to reload in order to fetch them. Reload is possible since Resgate, unlike the client, does not cache errors.
As said, this has never been much of an issue; if it would become one, it could be solved by updating Resgate and the RES protocol with one additional event. But this would also add to client complexity.
Or did you see some other scenario where transitioning from errors might be needed?