Post mortem analysis of remote scripts / telemetry

[kr1zz]

How can we tell what happened on the client side if they don't give us enough information?

We give the user a script, or they write it themselves, and run it on their machine to get some kind of results from WASDI. Then they experience an error and don't tell us what error, or can't (there are a lot of reasons why this happens: maybe they don't have acces to the machine where the script runs, maybe they are not IT, maybe they cannot disclose their logs), but they complain that it didn't work and need help: how can we know what happened? Can we help with this?

[kr1zz]

We should create some sort of telemetry service.
One dirty workaround is:

1. Create an app which does nothing. Call it telemetry_app or something like that
2. Add a helper function to the client script which takes a string (a log message) and adds it to the payload of the telemetry_app in that workspace. More precisely:
   1. check if the telemetry_app has already been executed in that workspace. If not, run it and wait for it (this is required only once)
   2. retrieve the payload of the telemetry_app
   3. add the message to said payload
   4. set the new payload of the telemetry_app with the updated content
3. intercept exceptions/errors and pass them to the telemetry_app

Then there's bell's and whistles:

1. the payload can easily grow very large, so we may want to have one instance per day, or maybe have a flag that signals that we reached the maximum tolerable size for the payload, and trigger the execution of a new instance of the telemetry_app
2. format the payload. For instance, it could contain a unique identifier of the run (e.g., timestamp of the starting time + UUID), and the messages related to that run are all inserted there (maybe each with their own timestamp). Now the helper function must remember the unique identifier, so maybe we need an object to store this state

[kr1zz]

In addition, having an API that allows to append to the payload, or merge it, rather than rewriting it entirely, would be helpful: we would be able to pass just the new part, rather than the entire payload back and forth. It would probably break the JSON format, but not retrocompatibility