Confirm
98
edits
Changes
describe some events
| event_object || varchar || The type of object being acted on
|-
| event_string_value || varchar || Always an empty string?Additional data
|-
| event_map_values || map(varchar, varchar) || Additional data specific to this event.
| submission_date_s3 || varchar || The date this ping was submitted.
|}
==== Event Usage ====
===== Commands sent between clients =====
Sometimes Sync will send a "command" from one device to another. The most obvious example of this is "send tab". Event telemetry is recorded both by the sending device and the receiving device.
In all cases, the sending device will create a unique "flowID" which will appear in event_flow_id, and it will send this value as part of the command. The device receiving the command will record this flow ID in the event it creates - so both the sending and receiving device will record the same flowID.
In all cases, the sending device will record in the event the ID of the device that is to receive the command. However, the receiving device does not record the device that sent the command.
The sending device will record: event_object="sendcommand", event_method will be the specific command being sent (eg, "displayURI" for sendTab).
The receiving device will record: event_object="processcommand", event_method will be the command being sent.
===== Commands sent by the repair process =====
Bookmark repair is fairly chatty when it comes to events - both the device initiating the repair and any other devices participating in the repair process record events, and they all use the same flowID - so it should be possible to reconstruct the repair process by looking for all events with the same flow ID.
The general repair process is:
# One device finds problems and starts a repair. It emits an event event_object="repair", event_method="started".
# It then attempts to find other devices able to help with the repair - if it finds any, it will emit event_object="repair", event_method="request", event_string_value="upload", and includes the device ID of the device it wants to respond - and waits.
# Hopefully the other device will see the repair request. If it finds any objects it can upload, it will emit an event event_object="repairResponse", event_method="uploading".
# Once the upload is complete, it will write an event event_object="repairResponse", event_method="finished".
# If the repair responder fails for some reason, it will emit event_object="repairResponse", event_method="failed" or "aborted"
# If initial device that sent the repair request doesn't see a response from the other device it will emit event_object="repair", event_method="silent". If the other device disappears completely, it will write event_object="repair", event_method="missing".
# The initial device will then check to see if it is still missing items, and if so, attempt to find a new client. If it can, it jumps back to (2) above.
# The initial device will eventually run out of clients, or will find all of its IDs. At that time it will emit event_object="repair", event_method="finished" - or if it gives up due to some error it will emit event_object="repair", event_method="failed"
whew! So in summary:
* every repair should emit event_object="repair", event_method="started" as it starts, and either event_object="repair", event_method="finished/failed" as the last event.
* There may be any number of repairResponse events written (including zero events if there are no suitable devices). Each of these should result in a event_object="repairResponse", event_method="finished/aborted"
=== Query Examples ===
