A stack trace tells you where an error happened, not how your driver got there. For bugs that depend on sequence or timing — a callback that runs in the wrong order, a proxy command that arrives before the driver is ready, a property that was set to something unexpected just before the failure — the trail of events leading up to the error is usually the thing you most want to see.

Anvil would automatically capture a rolling trail of recent activity for every driver instance: C4:* API calls, callback entries, property changes, timers, proxy messages, and outbound network requests, each with a timestamp and the relevant arguments. When your driver throws an error, or you call the Anvil SDK to capture one, the most recent slice of that trail goes along with the report. The stack trace shows the point of failure; the breadcrumb trail shows the run-up.

You can also add breadcrumbs of your own wherever something significant happens in your driver — a user action, a state transition, a branch in business logic — so the trail reflects meaningful moments rather than just raw API calls. The trail lives in memory on the controller and is only transmitted when it's attached to an error, so there's no steady stream of data leaving the device in the background. In the UI, breadcrumbs for an error can be filtered, searched, and expanded to show the full arguments for a specific call.