Summary:
A lot of the failures in the dashboard are due to unsupported android devices.
We can track this individually, but it shouldn't be affecting how reliable we think things are.
This adds an Error type, that when thrown, adds an extra field to log messages to specify that it's a known incompatibility.
Reviewed By: passy
Differential Revision: D15394863
fbshipit-source-id: 9d7948fbb8c94bd7a64434496e10392532a61eed
Summary:
I noticed that during a refactor, plugin success-rate failures started getting reported as successes.
Thankfully it's only the plugin metrics that are affected.
Reviewed By: passy
Differential Revision: D15394864
fbshipit-source-id: d9f44a0dd61f68dcdcbf2eb524821a3eb023231b
Summary:
At the moment, we can see the %-success of instrumented operations, but it's hard to attribute the ones that fail to actual errors.
This will allow us to see for every session-event row, the error messages that caused each of the failures.
Then if necessary, you can search for that error message in logview to get more info like the stack trace.
Requires a corresponding change in puma, since this is changing a number to a json value.
Reviewed By: danielbuechele
Differential Revision: D15099185
fbshipit-source-id: b966e6e55ab82f1cb9a4cfd7bf02034a1df01929
Summary:
Upgrading to flow 0.91, fixing a bunch of `$FloxFixMe`s that were introduced by upgrading to 0.86.
Also fixing some linting issues.
Reviewed By: priteshrnandgaonkar
Differential Revision: D13900794
fbshipit-source-id: 5d0a1b62371f3b5d34b909bae0876583acb6f977
Summary:
Adds an optional "plugin" field to the tracked metrics. The idea is to be able to see failures in plugins.
Added it around all desktop -> sdk "call"s, so it won't require any effort from developers but we'll get lots of immediate data. E.g. How often layout -> getNodes fails. I think we can go modify the existing pipeline to take both platform and plugin data so we can get session roll-ups too.
Corresponding change to the puma app: D13882629, adds a plugin field to all tables so we can filter by plugin, or null for platform failures.
I'm thinking it will be worthwhile to expose some method to plugin developers, that lets them explicitly track failures. It would be better if it encapsulated their plugin id etc, so they just need to say what failed. But that can be done any time, I don't have any particular use cases in mind yet.
Reviewed By: passy
Differential Revision: D13878379
fbshipit-source-id: 2e2ef6b98f763e6edcfe937741d6988dae4b92d1
Summary: Change from `recordSuccessMetric` to `reportPlatformFailures`, because the next diff adds `reportPluginFailures` and I want to distinguish the two.
Reviewed By: passy
Differential Revision: D13878380
fbshipit-source-id: 9c6b8bfe1ed2e1a8bbe5aacbec31d24e9aa39171
Summary:
The advantage of this is that anyone can now log without needing to carry around a Logger object.
Primary reason is for making metrics less intrusive in the codebase.
Reviewed By: passy
Differential Revision: D13671368
fbshipit-source-id: 162ab1351a124683aef13983fc3bcec01385cd1a
Summary: Wraps a future and records the success rate. This will be stored along with the sessionId and the userId, so we can drill down and get the success rate at different levels.
Reviewed By: passy
Differential Revision: D13635049
fbshipit-source-id: 4e0e6bdc0f9b76b08cf37c5d9fe87909f7338534
