Announcing workflow debugging
bitdrift Capture just got even more powerful: as of today, we’ve added workflow debugging! As we have worked with more and more customers, it has become extremely clear that one of the biggest side-effects of workflows being so flexible and powerful is the complexity of understanding whether a workflow state machine is going to properly match client-side events when it is deployed. Is there no data because there is actually no data or is there no data because one of the match conditions is incorrect when applied to device logs? That all ends today with one of the most powerful (and coolest!) features we have shipped to date.
Workflow refresher
Capture is a very different take on mobile observability. Instead of sending gobs of data from every mobile device to our backend for processing, most of which is never read, incurring high costs and mobile device performance overhead, we couple local storage and real-time control to collect data on the mobile device and only send it to the backend when it is explicitly requested. As we like to say, this provides 1000x the data when you need it, and none when you don’t. The main lever of real-time control is what we call the workflow. A workflow is the visual language for directly querying mobile devices, resulting in a finite state machine that is sent from the backend to every mobile device and tells the device what event sequences to look for, and what to do when that sequence occurs. For example: “Wait for the user to view the check out screen, then if the user leaves the checkout screen or 15s has passed without a checkout, increment a counter and dump a full session with session replay.” Workflows allow encoding very detailed conditions to match on, which allow you to debug extremely detailed cases without the noise of heaps of useless data that do not apply to the case at hand.Workflow composition challenges
Workflows are very powerful. They can also be very complicated depending on what is trying to be debugged. Match conditions can be very specific, and must match the logs that are generated on the device. When a workflow is created in the visual builder, it relies on specifying the right conditions, which might include regular expressions, matching on specific log fields, and so on. Time and time again Capture users have a typo in their workflow and are confused why there are no matches and no data flowing. Users have to wait for data to (not) show up, before they can assess if the workflow is correct. This is, frankly, a horrible user experience and we have known for a long time that we must fix it if Capture is ever to be widely used.The workflow debugger
For a long time we have supported live log tailing via our bd tail CLI tool. This is a great tool to see what logs are being emitted from devices in real-time. However it does not help with making sure that a workflow will match on those logs. Today we are shipping a real-time visual workflow debugger directly within our portal UI. The debugger has the following features:- Direct attachment to a development device via a short code.
- Live streaming of device logs similar to what bd tail offers on the CLI.
- Highly responsive (< 1s delay) visual indication of when different workflow steps are matched and executed, including step execution counts.
- Live views of resource utilization and session replay.