Just to preface this, I’m not really an expert at all with LEAF, and this project is my first time trying to interact with it, so apologies in advance if this is an obvious thing I’m not understanding about the toolset.
I’ve been trying to use the dataChangeEventManager to listen for changes to database records and update the state of the app being developed with fresh data from one of our fetching services when changes to certain records are detected. I used this documentation as a reference to set things up, and currently the setup is almost a carbon copy of what’s listed here: Sign in to LEAF
Initially I was getting trouble with the observable.subscribe call, where it appeared that the action was never being triggered and that the inner block of the code where we setup the constant dataChangeType was never being reached. I spoke to another member of the LEAF team and it was discovered that the websocket configuration itself was resulting in some form of issues with the streamDataManager call in the top level services.js file of the application. A direct output of the error from the firefox developer console is below.
Firefox can’t establish a connection to the server at ws://case.lynceus/case-service/web-socket/event-query.
error
bubbles: false
cancelBubble: false
cancelable: false
composed: false
currentTarget: null
defaultPrevented: false
eventPhase: 0
I’m not certain how to resolve this one, and was hoping that if anyone who was more familiar with LEAF than I am knew some troubleshooting steps I could take here, that I could possibly get some advice? Hopefully this is just something easy that I’ve missed, and doesn’t eat up too much of anyone’s time. Thank you in advance for any and all help.
It looks like the issue is that you are using the wrong path to your WebSocket service or you don’t have a WebSocket service setup at all. Tagging @platformservices so they can help you either set that up or found out what your correct WebSocket path is.
Hello Mark! Apologies for the delay 
As Caleb mentioned it looks like your client is unable to find your websocket endpoint. What generator did you use to build this service? @leaf/websocket-service? @leaf/data-service? Something else? Generated services also come with a config.txt file that is useful to help us troubleshoot. It tells us (and you) how the service was originally generated. That would be helpful to see here. If your service has correctly wired up a websocket endpoint, it’s possible that your ingress is incorrect. When a browser makes a request to a service running in a k8s cluster, it must go through an ingress rule (or virtual service in the case of Istio). Typically when I’m trying to troubleshoot a websocket connection, I use websocat. You can quickly rule out whether your service is the problem or if it’s a problem with your ingress by port-forwarding your service:
kubectl port-forward -n <your service's namespace> service/<your-service's-k8s-service-name> 8080:80
then you can verify whether your service has a web-socket endpoint with the following:
websocat ws://localhost:8080/web-socket/event-query
send anything and if you get something back your endpoint/service is valid and you know that the problem is not your service, but rather your ingress or virtual service (which the browser must send requests through)
You can generate a websocket-service to see how to correctly wire up the backend if you can’t find your endpoint by using websocat and taking kubernetes networking out of the equation by port-forwarding your service.
yo @leaf/websocket-service
1 Like
No worries, I’ve been working on a handful of other tickets in the meanwhile, so no rush or anything.
Sorry, I’ll try to answer these as best as I can, but I don’t really feel like I know what I’m doing with LEAF, so these answers might not be the most helpful unfortunately : /
In the services.js file we have here, where it looks like we’re setting up the endpoint configurations, it looks like we’re using leaf-core to do it. As far as the changes I have tried to make wrt the dataChangeEventManager, I was pulling that in from leaf/config/services. I don’t think I used either leaf/websocket-service yet not leaf/data-service. The online documentation I was getting pointed to before didn’t have instructions that mentioned those, so I didn’t know I would need them. If that’s one of those obvious things that other folks who are more experienced with this toolset would know about, then sorry if that was an obvious miss on my part.
Admittedly I’ve never messed much with ingress or k8 before this project either, so I don’t exactly think I know what I’m doing as far as troubleshooting the cluster if that’s the issue. I’ll try to download that tool and see if I can figure something out though, thanks for linking it, I appreciate it.
For posterity: @Mark.Vetro and I got on a call and worked through his issue. The 3 steps we took to get things working were:
-
Wire up the DataChangeEventManager to point towards their Websocket Service instead of their Data Service (which didn’t have an event-query endpoint).
-
Call .init() on the StreamDataWebSocketManager before we registered the DataChangeEventQuery.
-
Remove any filters on the DataChangeEventQuery. We were inadvertently filtering out the DataChangeEvents that we actually cared about. Now that we found out exactly what type of DataObjects were being modified, we can add the correct filters to the DCEQ.