forward error messages to the probe client

[patrykcieszkowski]

forward error messages to the probe client

[jimaek]

We can help the user and ourselves with more debug info too. For example when the probe connects to the API successfully we can output to the user information about the probe that we detected, like the city, country, version and later benchmark info. This way the user can immediately see if everything worked or not.
And it will be easier for us when the user opens an issue he can just copy paste the output instead of us having to look into our logs for basic stuff.

Maybe its simple enough to make it part of this task?

[patrykcieszkowski]

@jimaek that change would be fitting for this ticket, but I'm not convinced if user should actually see this data? They know their location better than we do

[jimaek]

Exactly so they would be able to catch a problem in our detection logic. Since we have no way of knowing if the location we detected is correct.

[zarianec]

Exactly so they would be able to catch a problem in our detection logic.

Also, there is no way to manually override the probe location info. It means that both sides will know about the issue but non will be able to fix it 🙁

[jimaek]

Yes, but at least we will know how big of a problem that is. e.g. maybe its correct 99.9% of times and we dont need a manual override logic. Or maybe we start getting tickets every day and will need to completely rethink our geoIP logic. Who knows.

[patrykcieszkowski]

do we want to forward any additional details to the probe, or just an error message?

[jimaek]

The more info the better I think but what else is there to forward?

[patrykcieszkowski]

so for the IP limit, we can pass on info about the other probe we've detected for instance.

For the VPN we also have the fastly client object, cointaining VPN details - but that might just help them to bypass the verification.

[zarianec]

but that might just help them to bypass the verification.

agree, we should remember that probes not under our control so we must limit the amount of information we show there.

[jimaek]

Yeah VPN info is probably not a good idea, just maybe say the reason we disconnected them so it would be clear it's not broken we just don't allow anonymous services like VPNs

[jimaek]

Btw don't forget since the API will be also open source there is not much to hide there:)