Debug Payload

[afolarin]

It would be useful to perhaps have a participant trigger this via the app and/or remotely triggerable?

Perhaps we can collect suggestions as to what this payload might include:

• date, time
• UUID
• wifi connectivity
• number of records in the cache
• authentication status
• sources connected
  ... etc

[blootsvoets]

Data that is already being collected:

• date, time (every plugin)
• UUID (every plugin)
• number of records in the cache (application plugin)
• authentication status (automatic, if not authenticated, no data is collected)

Data that is not collected:

• sources connected
• wifi / data connectivity

Is there a specific need to have these last two metrics? And to have them sent on command, rather than in the background? The former does seem useful, perhaps even as a full connection log (connected, disconnected, etc.).

[afolarin]

Data that is not collected:
sources connected
wifi / data connectivity

just thinking of reporting paired wearables, and we often have a question over the participant's wifi connectivity, wifi performance would be useful but not sure how easy that would be to derive without an external call to some bandwidth testing service.

Is there a specific need to have these last two metrics? And to have them sent on command, rather than in the background? The former does seem useful, perhaps even as a full connection log (connected, disconnected, etc.).

Yes If the data is already periodically reported that's good (I should take a look), being able to trigger it by the participant/or remotely might otherwise be handy for troubleshooting situations perhaps say someone experiences a transient problem they could be instructed to trigger the payload?

[blootsvoets]

Okay, from this I gather the following associated feature requests would solve the issues

• add an action for the ApplicationStatusProvider to show app metrics and if pressed, send them immediately instead of waiting for the next interval.
• instrument the Kafka sender to report latency and failed calls, used in the ApplicationStatusProvider.
• Send the already instrumented plugin state transitions (CONNECTED, CONNECTING, READY, DISCONNECTED) from the ApplicationStatusProvider. This will be a high-frequent topic whenever the app is started or stopped though.

These changes seem like a useful additions to the current code base.