Updated 31 August. The editor bug behind all of this is fixed (KrishnaTO/ARI-metadata-manager#147). The original version of this issue told you to expect red builds and how to clear them; that advice is now wrong and has been replaced. The history is at the bottom.
What changed
The editor used to write the whole ontology from a copy loaded when your session started, so your save reverted anything merged since — other people's confirmations, synonyms, subtypes, cleanup work — even when you only touched one disease. Between 17 and 30 August that cost main 208 synonyms, 57 clinical subtypes and roughly 100 review records, and reverted three completed cleanup branches.
Some of you re-reviewed pairs you had already judged, because your first judgment had been wiped and the pair showed up as unreviewed again. None of that was a curation mistake, and it was never visible to you.
All of it has been restored (#78, #80), with original attribution intact — a judgment you made and lost is credited to you, not to whoever re-made it afterwards.
Two things to expect now
1. A publish can fail with a 409 in the editor. Publishing now rebases onto the current branch. If a disease you touched also changed upstream, the publish stops and names the diseases instead of quietly overwriting them. This is the fix working. Reload so you pick up the current state, redo the edit on that disease, and publish again.
2. A red CI build now means something real. Validate mappings fails on record-deleted, xref-deleted or disease-deleted — a pull request removing curation nobody reviewed. With the rebase in place this should be rare. If you see one, it is not routine:
error record-deleted ARI:0001098 loses 1 changelog entry(s) this branch did not add:
'2026-08-21 17:35 | linikujp | Cross-reference review: confirmed MONDO 0850054...'
Do not merge past it, and do not assume it is the old problem. Comment here with the PR number.
A cross-reference you deliberately flagged wrong on the review page is still removed without complaint — that judgment is recorded in the mapping set and the check honours it. Repairing a malformed value is exempt too. Only unreviewed removals fail.
Confirming a term now stores the id
It used to write a mapping row and a changelog line and nothing else, so confirming a term the registry did not already hold changed nothing anyone could see. That stranded 30 confirmed cross-references across 16 diseases — mostly MONDO and Orphanet, which the original ARI import barely carried. Those are stored now, and new confirmations store the id as they are made.
One thing to check before you rely on this
KrishnaTO/ARI-metadata-manager#147 is merged, but merged is not the same as deployed. If the editor at aurint.ca has not been redeployed since 31 August, you are still publishing with the old code and the old behaviour. Worth confirming before a large review session.
Original text, 31 August — superseded
The original issue told curators that red builds were expected, that the remedy was to start a fresh editor session and re-publish, and that if that did not clear it the stale copy might be shared server-side and should be reported. The editor now rebases automatically, so the first two no longer apply, and the third was answered by the fix.
What changed
The editor used to write the whole ontology from a copy loaded when your session started, so your save reverted anything merged since — other people's confirmations, synonyms, subtypes, cleanup work — even when you only touched one disease. Between 17 and 30 August that cost
main208 synonyms, 57 clinical subtypes and roughly 100 review records, and reverted three completed cleanup branches.Some of you re-reviewed pairs you had already judged, because your first judgment had been wiped and the pair showed up as unreviewed again. None of that was a curation mistake, and it was never visible to you.
All of it has been restored (#78, #80), with original attribution intact — a judgment you made and lost is credited to you, not to whoever re-made it afterwards.
Two things to expect now
1. A publish can fail with a 409 in the editor. Publishing now rebases onto the current branch. If a disease you touched also changed upstream, the publish stops and names the diseases instead of quietly overwriting them. This is the fix working. Reload so you pick up the current state, redo the edit on that disease, and publish again.
2. A red CI build now means something real.
Validate mappingsfails onrecord-deleted,xref-deletedordisease-deleted— a pull request removing curation nobody reviewed. With the rebase in place this should be rare. If you see one, it is not routine:Do not merge past it, and do not assume it is the old problem. Comment here with the PR number.
A cross-reference you deliberately flagged wrong on the review page is still removed without complaint — that judgment is recorded in the mapping set and the check honours it. Repairing a malformed value is exempt too. Only unreviewed removals fail.
Confirming a term now stores the id
It used to write a mapping row and a changelog line and nothing else, so confirming a term the registry did not already hold changed nothing anyone could see. That stranded 30 confirmed cross-references across 16 diseases — mostly MONDO and Orphanet, which the original ARI import barely carried. Those are stored now, and new confirmations store the id as they are made.
One thing to check before you rely on this
KrishnaTO/ARI-metadata-manager#147 is merged, but merged is not the same as deployed. If the editor at aurint.ca has not been redeployed since 31 August, you are still publishing with the old code and the old behaviour. Worth confirming before a large review session.
Original text, 31 August — superseded
The original issue told curators that red builds were expected, that the remedy was to start a fresh editor session and re-publish, and that if that did not clear it the stale copy might be shared server-side and should be reported. The editor now rebases automatically, so the first two no longer apply, and the third was answered by the fix.