Skip to main content

Issues: failure fingerprinting

The same bug across every run collapses into one issue.

Task failures group by a stable fingerprint built from the exception the adapter reports and the deepest traceback frames, with volatile noise (memory addresses, UUIDs, object reprs, long numeric ids) stripped out. The same bug across many runs collapses into a single issue instead of a wall of near-identical failures. Each issue tracks its occurrence count, whether it is currently open or recovered, when it was first and last seen, and which engines it has shown up on.

Ships with

  • Stable fingerprint: reported exception plus the deepest traceback frames, volatile noise stripped
  • The same failure across runs collapses to one issue
  • Occurrence counts so you see how often a signature is firing
  • Open vs recovered state so a fixed bug stops shouting
  • First-seen and last-seen timestamps on every issue
  • Engines-affected list on every issue

Highlights

  • Automation rules can condition on an issue fingerprint, so a rule fires for one signature only
  • Turns a noisy failure feed into a short, deduplicated list of real problems

Related

More capabilities

Ready to try z4j?