That's a fallback in case WebSocket is failing, so we don't want to surface those errors. That's expected and intended behavior.
Yes Sir, and that's a good decision avoiding showing error in prod, but feels like sometimes either the fetches fail or they're is an error that stop the WebSocket from retrying, the hint is that the error didn't occur in all cases with the same phone sometimes it fails and never retry to refetch data.
What about adding an socket.onerror case in addition to the onclose?
For the WebSocket we don't include any errors. It sounds to me like you're still confusing main connection and the fallback.
I'm able to make a reproducible step environment, the problem occur when in reality when you lost connection will the app is in background, for example you could open the app, put it on the Background and change connection from wifi o 4g wait for a moment an reopen the app from the background, the data won't be fetched until you restart the app
Have you tested both iOS and Android?
Hi Anton,
Sorry for being late, I just want to be sure that the problem occur and have an idea on why this is happening before responding, the problem in reality is with websocket in general, the problem occur when device lost internet - you can try it when you disable wifi, make application in background wait a moment enable mobile data - you'll notice that data will not refresh, the cause is that the websocket isn't aware of the loss of internet, and onclose aren't fired, I made a search, firing event on window.online are one of the solution but it's not reliable, I found that adding a ping/pong frame to check if the client is always connected but I'm not sure if this is a good solution, it will make the server busy, add new requests to server every x seconds and from the client side it can drain battery more faster ...
I prefer to know what do you think about that, I can join some StackOverflow links concerning the websocket issue
And yes the problem occur on iOS and Android
I think a regular ping from the web app makes sense. We do have a keepalive message from the server.
Is there any info or updates regarding this? I am having the same issue using the latest 5.6 version. When having a connected device in Traccar Manager, if the app is not fully closed and left running in the background and then re-opened 10-15 minutes later the app does not update with any location data until properly closed. The only other way I find it updates itself is to open the settings menu and click on the info tab on the Manager app.
No updates. If anyone is interested in investigating this, feel free. Pull requests are welcome.
I'll try to do my best to solve it.
Thank you B.lhab, for myself the android version doesn’t have this updating after being in background issue. I forgot to mention, when the socket is in its sleep state there are no updates for ignition status or command results ect either until selecting the setting box or force closing the app
Hi again, I did some changes, but it doesn't seem to work on iOS, I want to share what I did with you guys, then we can check if I'm in the right way and improve/give some idea, where can I put the code for review?
Feel free to create a PR and we can discuss there.
Hi guys, I hope you're doing fine, I can validate that the issue is still existing, I'm using the last version of Traccar 5.6, tested on multiple phone - Iphone 12 Pro, S20 Plus ... - the issue doesn't occur every time, sometimes you got the positions refreshed sometimes not, tested with different duration on background.
I thought about one of the conditions aren't satisfied or an error that occur but since we don't catch error it's a little bit hard to debug:
if (event.code !== logoutCode) { try { const devicesResponse = await fetch('/api/devices'); if (devicesResponse.ok) { dispatch(devicesActions.update(await devicesResponse.json())); } const positionsResponse = await fetch('/api/positions'); if (positionsResponse.ok) { dispatch(sessionActions.updatePositions(await positionsResponse.json())); } if (devicesResponse.status === 401 || positionsResponse.status === 401) { navigate('/login'); } } catch (error) { // ignore errors } setTimeout(() => connectSocket(), 60000);
Concerning the Timeout can't be decreased a little?