@MathieuGuindon just to point out - you should make sure that the race condition is handled (e.g. client starts to connect but then the timeout expires due to running on a different thread, and client then get an exception) - so that it can just restart the server as well as handle the case where client dies without telling the server about it dying (how rude!)
@this we're getting the correlation IDs and trackable requests and everything
#BecauseWhyNot
so, I'll just add a TelemetryClientCapanilities class with a TelemetryOptions, and then it should just plug into the initialization code
and, it's inherently opt-in
I'm tired of knowing exactly nothing of how RD is used, what inspections fire results, how commonly we save anyone's ass, etc.
hopefully at least one or two users opt-in :D
The aggregated metrics could make some pretty interesting daily summaries..
The telemetry client is going to hit an api.rubberduckvba.com endpoint that'll accept the payloads through https, could require GH authentication if we want.
The telemetry payloads are going to be written to localdb in any case
That way whether trace output is enabled or not, detailed troubleshooting data exists and can be pulled locally and reviewed before sharing
@MathieuGuindon If telemetry is written to localdb, then for those who would like to participate, but whose corporate IT prevents them from doing so, there could be an Manually Export Telemetry option that would generate a file (JSON/XML) that could be manually uploaded to GH (or somewhere) then parsed and imported to the GlobalTelemetrydb
Not nearly as slick as auto upload, but it gets around the corporate nannies in a fully 100% legit way. It also gives the employee an opportunity to show IT exactly what would be uploaded if it were allowed to be done automatically, and might actually serve to get an IT green light.
> Hi @inventordev , I have been using this patch with Inventor 2022 and it does allow Rubberduck to work. However, I often get an "Unexpected Error" from Rubberduck during refresh when I have Inventor files open. Have you had any similar issues?
var server = new LocalDbServer(Settings.Default.JsonRpcServerPath, startupOptions.Port, console, startupOptions.Interactive, TimeSpan.FromMilliseconds(startupOptions.ExitDelayMilliseconds));
server.Start();
while (server.IsAlive)
{
}
Well, while loop is a beautiful thing but it is enemy of the CPU.
Instead of while, I often use ManualResetEvent class to prevent closing console apps.
Usually it works when i use this code block in Linux containers on Docker.
I don't have the actual code block, I am going to remember it like;
...
var server = new LocalDbServer(Settings.Default.JsonRpcServerPath, startupOptions.Port, console, startupOptions.Interactive, TimeSpan.FromMilliseconds(startupOptions.ExitDelayMilliseconds));
server.Start();
_shutdownSignal.WaitOne();
Ok, shutdown signal is in place, server will exit after the last client has disconnected. Now the fun part: handling and responding to the initialize request..
might have to tweak RPC-level message handling to correctly handle losing the db server on the LSP side
Tonight the goal is to get into bed by midnight the DB client app to successfully communicate with the localdb server. If I get that quickly I'll script the tables for the telemetry model and prepare the data layer for it.