Condition text automatch - record when the Monarch search failed so it can be retried
- Dominant language
- Python
- Stars
- 30
- Forks
- 3
- Avg merge
- 9h 28m
- Merged PRs (30d)
- 42
Description
🤖 Written by Claude
When the Monarch search fails during automatch, `ConditionTextMatch.attempt_automatch` (`classification/models/condition_text_matching.py:285`) catches the error, reports it and assigns no terms. The condition text is left unmatched — which is indistinguishable from Monarch legitimately finding no match.
Two consequences:
- **Users can't tell.** The condition matching page falls back to local OMIM matching and shows that (or nothing) as the suggestion. Nothing says the MONDO search never ran, so a curator may accept a worse suggestion, or manually curate a text that automatch would have matched.
- **Nothing re-attempts it.** `ConditionTextMatch.sync_all()` is only reachable via the `sync_condition_text_matches` management command — it isn't in celery beat. `attempt_automatch` otherwise only fires when a classification with that text is published or synced. So an outage during an import leaves a batch of texts permanently unmatched, with no way to identify which ones, short of re-running the full sweep over every `ConditionText`.
## Proposed
Record the fact of the failure, not the response body. A nullable `search_failed` timestamp on `ConditionText`, set when the search raises in `attempt_automatch`, cleared on the next successful search:
- the condition matching page can show "automatch didn't complete - suggestions may be incomplete";
- a periodic task (or the existing management command) can re-attempt just those rows.
Set it in `attempt_automatch` only — `condition_matching_suggestions` runs on page view, and writing from a GET during an outage isn't wanted.
## Deliberately not storing the error response
The response body's value decays within minutes, and Rollbar already keeps it (see #1742 for making that report legible). `ConditionText` is a deduped derived record, one per `(normalized_text, lab)`, deleted by `sync_all` once `classifications_count` hits 0 — it isn't an audit log. It also only covers one caller: `ontology_matching.py:337` is the interactive user search, with no `ConditionText` to attach anything to.
Separate from #1742, which is only about the propagated error naming Monarch as its cause.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.