Building a small internal dashboard on top of the MCP server. There appear to be three ways to get at healing data and I cannot tell from the tool descriptions where the boundaries are:
heal_eventsheal_locator_statssdods heal reportDo any of them need a database? And is heal_locator_stats the same aggregation the CLI does, or a different one?
Accepted answer
None of the three needs a database. All of them read the heal.jsonl files under the artifacts directory.
heal_events is one run: pass a runId, or omit it and it takes the most recent, optionally filtered by project. Each event comes back decorated with the scenario fingerprint, the retry number and the scenario name, which is the part the CLI table does not give you.heal_locator_stats aggregates across recent runs — thirty by default — keyed on the original selector, with occurrences, a count per winning strategy and the suggested selector.sdods heal report is the same shape of aggregation, over one run by default or every run with --all.For a dashboard I would use heal_locator_stats for the table and heal_events for the drill-down, because the fingerprint is what lets you join a heal back to a scenario.
One correction worth building in. The two aggregations key differently: the CLI keys on description plus original selector, the MCP tool keys on the original selector alone. If two page objects declare different descriptions over the same selector you get two rows from one and one row from the other. Neither is wrong, but do not diff them and conclude something is broken.
A database only enters the picture a level up, at insights — locator fragility is computed from locator_stats, which needs ingested runs.
From having built roughly this: put pageUrl on the drill-down. Selector and description tell you what healed, the URL tells you where, and without the third one you spend a lot of time guessing which of four pages a shared component was on.
Have a different question? Ask it.