Classification - run condition text automatch as an async task, batched per import #1780 - #1781
Open
davmlaw wants to merge 4 commits into
Open
Classification - run condition text automatch as an async task, batched per import #1780#1781davmlaw wants to merge 4 commits into
davmlaw wants to merge 4 commits into
Conversation
davmlaw
force-pushed
the
condition_automatch_async
branch
from
August 26, 2026 07:43
52915cd to
b809f93
Compare
…ged against a rolled-back user #1780
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 Written by Claude
Addresses #1780 — during a Shariant upload, condition text automatching ran synchronously in the publish signal and could call the external Monarch search API per record (60s timeout + retry), crawling the whole upload when Monarch was slow or down.
Design
Publishing no longer automatches at all — it just sets a flag, and a periodic sweep does the external work. There is no task dispatch, no signal-driven queuing, and no explicit locking:
ConditionText.pending_automatch(new field + migration):sync_condition_text_classificationsets it when a new root/gene level appears (the case that previously triggered the inlineattempt_automatch) and does the quick count update. The flag is written in the same transaction as the publish, so it can't be lost, and it's the crash recovery — anything a dead worker leaves behind is picked up by the next sweep.condition_text_automatch_task— a celery beat sweep every 5 minutes (same shape asreclassification_events_update). While aClassificationImportRunis ongoing it stands aside, so a whole Shariant sync accumulates flags and the first sweep after completion drains them as one batch, deduped to one automatch per distinct condition text. Each text is claimed with a single-statementUPDATE ... WHERE pending_automatchbefore its automatch, so overlapping sweeps can't process the same text twice, and the Monarch call itself runs outside any transaction with no rows locked.attempt_automatchitself is unchanged (it still does the full count recompute), soConditionTextMatch.sync_all()from the management resync path behaves exactly as before.The Shariant sync uploader passes
import_id, so it gets the batched path: the API accepts and returns quickly, and Monarch is hit at most once per distinct condition text, after the import completes, on a db worker.Testing
classification/tests/models/test_condition_text_automatch.pycovers the sweep's claim-once-and-clear behaviour and that it defers while an import run is ongoing then drains afterwards.classificationsuite passes (141 tests).🤖 Generated with Claude Code