Thanks for the confirmation. I can start by explaining a little about what we suppose happened here.
The unattended (Windows Service) component maintains a connection to Wayk Den, that is used to serve incoming connections. When you start the Wayk Now client, it connects to the service and the status and Wayk ID that you see in the UI are from the service's Den connection.
If you start the Wayk Now client and the unattended service is not running, Wayk Now launches it's *own* Den connection, and the status and Wayk ID in the UI will be from that connection.
Although the Den connections are from the same machine, they are different - and would have a distinct Wayk ID and unique ID.
Here is what I suppose happens in this case:
- An error causes the unattended service to stop or crash. Incoming connections will now not work. The running Wayk Now client can no longer retrieve the Den information from the service, so the status goes to red / "disconnected from Wayk Den".
- The Wayk Now client is closed, and then re-opened.
- Since the service is not running, the client starts in "attended" mode, launches it's own Den connection, so from the user perspective, the Wayk ID and unique ID appear to have changed.
- Worse - at this point, having noted the "changed" Wayk ID / unique ID, the Wayk Now client is closed. Incoming connections still will not work - because neither the service nor the client are running to service them.
There are obviously at least three things that require our attention here:
First, the UX around a disconnected service is not good. It can be unclear whether the Wayk ID will be "available" if the client application is closed, and the Wayk ID can appear to arbitrarily change. We have already made improvements here - in the next version of Wayk Now, the client application shows an unobtrusive warning if the service appears to be, or goes, offline. This should make it clear if there will be a problem servicing unattended connections.
Second, the service should not crash or stop unexpectedly. We expect the service to be stable, and in the majority of cases that is the case. If you do see crashes or unexpected failures like this, it is very helpful if you can share diagnostic information with us (please see my third point below), especially if the problem is occurring often or repeatedly. Service crashes and failures should *not* be the norm, and anything that we can follow up on will get our full attention. Furthermore, we are investigating approaches to detect and automate recovery in the case that a failure does happen - the UI improvements mentioned above are the first part of that.
Third, we understand that it is not alway straightforward to share diagnostic data in the case of a failure. Please note that the service does log automatically (as of 2019.2.0) without user intervention, and the file can be found in %programdata%\wayk\logs\nowservice.log. This is another area where we are targeting improvements, however. The unattended service is a hybrid C / rust application - a crash or failure on the rust side should be captured in the log file, but may not be if it occurs in the C pieces. We are working in integrating some better tools to capture failures in all parts of the code, and a second phase of that will be to (optionally) automatically send the reports back to us for analysis.
We thank you for your continued support and patience. As I said - if the issue is occurs, at this point I can only encourage you to provide the log file from the service for analysis, if possible. However I hope the above gives some insight into the changing Wayk ID issue, what can be done about it, and the steps we have and are taking to fix that.
Thanks and kind regards,