Taxon deletion nulls determination.TaxonID outside the delete's transaction — failed/cancelled deletes silently orphan determinations at scale

[urban011]

Summary

Deleting a taxon node clears TaxonID and PreferredTaxonID on every determination referencing that node and its descendants, and that clearing survives when the delete itself does not complete. The taxon stays in the tree; its determinations are left blank.

At UT Austin's Vertebrate Paleontology collection (VPL) this silently unlinked 10,829 determinations across 273 taxa in a single working day, during an ordinary taxon-tree cleanup session. It was not noticed for twelve months. Total confirmed impact on this instance is 8,639 determinations across two separate collections (8,631 in VPL, 8 in our non-vertebrate paleo collection over 2021–2025 — see "It is not one collection" below).

This is not related to #8064. Separate bug, separate mechanism.

Environment

• Specify 7 v7.12.0.7
• MariaDB 11.4.10
• Upgrade applied 2025-08-28 (migrations specify.0001_initial → workbench.0008_spdataset_rolledback)
• Damage began 2025-08-29 08:50 local, the following morning

What we observed

On 2025-08-29, determination rows lost both TaxonID and PreferredTaxonID in ~70–100 discrete bursts of 15–20 rows/second spread through the working day. spauditlog for that day records:

TableNum	Action	FieldName	count
9 (Determination)	1 (update)	taxon_id	8,962
9	1	taxon	29
4 (Taxon)	2 (remove)	(all fields)	20

The 2022 rows show the failed-delete path is old — two records in four years, against 10,829 in one morning after the upgrade. Our read is that the upgrade removed a guardrail (and shipped the #5324 subtree-delete feature to this instance for the first time) rather than introducing the defect. We have instructed our collection manager to stop deleting taxon nodes entirely.

It is not one collection

We checked all nine Specify schemas on this instance with the same audit-log fingerprint (TableNum 9, FieldName taxon_id/taxon, OldValue set, NewValue empty, determination currently blank). A second collection — NPL, non-vertebrate paleontology, a separate database with a separate taxon tree — had 8 more, scattered from 2021-10-26 to 2025-11-13, all pointing at taxa that still exist. Same signature, different database, four-year span. The other seven schemas were clean.

Total repaired on this instance: 8,639 determinations across two collections.

Possibly related existing issues

• Handle deletion failed due to delete blockers #1748 (open since 2022-06) — "Handle deletion failed due to delete blockers." Our earliest losses are June 2022.
• Refactor and refine cascade deletion rules #2806 (open) — "Refactor and refine cascade deletion rules."
• Deleting an agent attempts to delete any Taxon trees they creating #8418 (open, 2026-08) — deleting an agent attempts to delete taxon trees they created; same on_delete=CASCADE class.
• Allow cascading deletion of tree nodes and unused children #5324 (v7.10.0) — the delete-node-with-unused-children feature; our instance first received it in the 2025-08-28 upgrade, and the mass event was the following morning.

Why this is severe

• Silent. No error, no warning, no count shown to the user. The determination simply goes blank.
• Undetectable by the user. A collection manager querying "current determination with empty taxon" cannot distinguish these from genuinely undetermined material.
• Unbounded. One delete attempt on a high-level node takes out every determination beneath it. Equidae alone accounted for 2,000 records, Mammalia 766, Vertebrata 504.
• Recoverable only by luck. We recovered because auditing was enabled and we still had a monthly dump from four weeks before the incident. An institution with 30-day retention and auditing off would have lost this permanently, and would not have known for a year.

Secondary concern in the same migration

Independent of the bug above: on_delete=CASCADE on taxon.parent means deleting a family node silently deletes every genus and species beneath it. For a taxonomic tree in a collections management system that seems like a dangerous default, particularly with no user-facing confirmation of how many descendants are in scope. Same applies to geography, storage and lithostrat.

Suggested fix

1. Put the reference-clearing and the delete in one atomic block, so a refused delete rolls the clearing back.
2. Before clearing anything, show the user how many determinations and descendant nodes the delete will affect, and require confirmation.
3. Consider refusing outright, as pre-upgrade behaviour did, when determinations reference the node.

What we can supply

• spauditlog / spauditlogfield extracts for the affected window
• The full list of 273 affected taxa with per-taxon record counts
• SHOW CREATE TABLE determination and the full applied-migration list with timestamps
• A pre-incident and post-incident dump of determination for diffing

Happy to test a fix against a copy of the collection.

How we repaired it

For anyone hitting this before a fix ships. Two independent sources, reconciled before writing:

1. spauditlogfield.OldValue where TableNum = 9, FieldName IN ('taxon_id','taxon'), OldValue set and NewValue empty, deduplicated to the latest nulling event per determination.
2. A pre-incident mysqldump, loaded into a scratch schema and joined on DeterminationID.

The two agreed on all 8,574 records they shared, with zero conflicts. PreferredTaxonID was recomputed as COALESCE(taxon.AcceptedID, taxon.TaxonID), a rule validated against 8,574 historical values before use. Post-restore, preferred-taxon consistency across the entire determination table checks clean.

[grantfitzsimmons]

Hi @urban011,

Thanks for your report. I have a few questions:

• How was the deletion initiated?
  • Was the taxon deletion performed through Specify 7's tree form (clicking the Delete icon on a node in the tree viewer or deleting from the form)?
  • Was it performed via a script/API call, Workbench, Batch Edit, a tree merge/synonymize action, or a direct database edit?
• When the deletion attempt failed or left the taxon in the tree, did you see an error pop-up or a 500 error in the browser/logs? Do you recall if the delete blockers dialog appeared before attempting the delete, or if the red Delete button was active?
• If possible, could you send us a full backup of the most recent copy of the database so we can inspect the schema constraints, storage engines, and audit log entries directly? https://discourse.specifysoftware.org/t/send-a-backup-to-specify/767
• If you can't send the database, could you let us know if the determination table or related tables are using the InnoDB or MyISAM storage engine? (SHOW TABLE STATUS LIKE 'determination';)

[grantfitzsimmons]

Feel free to try and recreate this on our sp7demofish instance using the latest version of Specify 7 (v7.12.1-prerelease):

❯ curl -X DELETE 'https://sp7demofish.specifycloud.org/api/specify/taxon/946/' \
  -b 'csrftoken=rjwU85gbDUPDV3ZthrxRJLjFTCBapGQw; collection=4' \
  -H 'X-CSRFToken: rjwU85gbDUPDV3ZthrxRJLjFTCBapGQw' \
  -H 'referer: https://sp7demofish.specifycloud.org/'

{"exception": "ProtectedError", "message": "Cannot delete some instances of model 'Taxon' because they are referenced through protected foreign keys: 'Taxon.parent'.\", {<Determination: Determination object (31627)>, <Determination: Determination object (31628)>, <Determination: Determination object (29325)>, <Determination: Determination object (29326)>, <Determination: Determination object (31629)>, <Determination: Determination object (29327)>, <Determination: Determination object (24086)>, <Determination: Determination object (50456)>, <Determination: Determination object (29593)>, <Determination: Determination object (29595)>, <Determination: Determination object (20131)>, <Determination: Determination object (30887)>, <Determination: Determination object (14969)>, <Determination: Determination object (29362)>, <Determination: Determination object (9271)>, <Determination: Determination object (18239)>, <Determination: Determination object (31938)>, <Determination: Determination object (29251)>, <Determination: Determination object (29252)>, <Determination: Determination object (11975)>, <Determination: Determination object (13769)>, <Determination: Determination object (23370)>, <Determination: Determination object (9812)>, <Determination: Determination object (3925)>, <Determination: Determination object (17114)>, <Determination: Determination object (29279)>, <Determination: Determination object (10211)>, <Determination: Determination object (31080)>, <Determination: Determination object (52203)>, <Determination: Determination object (14318)>, <Determination: Determination object (29934)>, <Determination: Determination object

[urban011]

Thanks Grant. Answers in order, then a note on why the curl repro won't show it.

How it was initiated. Through the Specify 7 web UI, by our collection manager, in an interactive taxon tree cleanup session. Not WorkBench or Batch Edit (no matching datasets in spdataset), not a script or API call (he is non-technical), not direct DB edits (every change sits in spauditlog under his agent, and the 20 deletions that completed are ordinary rename-then-delete duplicate cleanup, names like Pachycheilosuchus2 and HelaletesXXX). I'll ask him whether he used the delete icon in the tree viewer or the form and what dialogs he saw, but this was a year ago so I don't expect much recall.

Errors seen at the time. Same caveat, and server logs from 2025-08-29 are long rotated. Two things stand in for it. Equidae (~2,000 referencing determinations) shows nulling bursts from 11:18 to 21:27 the same day, repeated attempts on the same node hours apart. That reads as fail-and-retry, not changes of mind. And this is the instance affected by #8064: heavy requests on this collection routinely run to gunicorn's 300 s timeout and get SIGKILLed. The likely experience was a long spinner, then an error, then a retry.

I strongly suspect the curl test won't reproduce it. Your ProtectedError with no writes matches our end state, but we believe the damage needs a second ingredient your demo instance doesn't have: the request has to die partway through. The orphans here were created during the worker hangs VPL experiences from #8064. A healthy instance either completes the delete or refuses it cleanly. Ours got far enough to commit bulk UPDATEs clearing TaxonID and PreferredTaxonID (8,950 audit entries naming the field taxon_id, queryset-style, vs 29 as taxon, form-style) and then never finished. To reproduce, I'd try the tree viewer delete on a node whose subtree carries determinations while forcing the failure: SIGKILL or SIGSTOP the worker mid-request, or set the worker timeout artificially low. Watching the general query log for UPDATE determination SET TaxonID = NULL ahead of the DELETE would confirm the write ordering either way. This also predicts which deployments are exposed: collections already affected by #8064.

Storage engine. InnoDB. The determination table carries six FK constraints, all RESTRICT/RESTRICT, which MyISAM cannot do. MariaDB 11.4.10.

Backup. Yes, we can send a current full backup of the VPL database through the discourse process. We also have a pre-repair snapshot of the determination table and complete audit log extracts for the event window if something lighter is useful. Note the database is post-repair: we restored the 8,631 affected determinations on 2026-08-20 from the audit log cross-checked against a pre-incident dump, so the damage is visible in the audit trail and our snapshots, not in current state.

Let me know which would help most and I'll get the backup moving.

[urban011]

Answer from our collection manager on how the operations were initiated, and it changes the picture in a useful way.

His practice: deletions only ever through the tree viewer, only after checking the name is unused, and when a delete fails he recalls a clear "term was not deleted" error. He is certain he would never attempt a plain delete on a name linked to thousands of records. But — his words — "these 'deletes' have to be from merging taxon names using the taxon tree. There is no way that I would delete taxonomic records that were connected to thousands of records otherwise. This would make sense with the timing too, because prior to that, I could not merge taxonomic names. Using the workbench tends to result in the odd 'new' taxonomic name being created that I will need to later merge because it's linked to a large number of records."

That reconciles with our forensics better than the delete framing in my original report:

The 20 taxa actually deleted on 2025-08-29 are exactly workbench-duplicate names (Pachycheilosuchus2, Pachycheilosuchus2 trinquei2, HelaletesXXX). A completed merge ends by deleting the source node — those 20 are the merges that finished.
A merge that dies after clearing references but before repointing them leaves precisely what we found: determinations with TaxonID/PreferredTaxonID nulled, the source taxon still in the tree (432 of 437 referenced taxa still exist), and almost no repointing entries (8,950 nullings vs 41 repoints in the audit log that day).
The timing matches your migration set: notifications.0003_spmerging arrived with our 2025-08-28 upgrade, and the curator confirms merge became available to him then. First day of merging = the mass event.
#7338 (merge-updated determinations missing from the audit log) may be related — if the repoint phase is under-audited, failed merges would look even more nulling-heavy in the log than they were.

So the defect is most likely in the taxon merge path, not plain delete — which also explains why the curl DELETE repro shows a clean ProtectedError refusal. Suggested repro: on a collection with worker recycling or a low timeout, start a tree merge of a taxon carrying a few thousand determinations and kill the worker (or the async task) mid-merge. Then check whether UPDATE determination SET TaxonID = NULL committed without the corresponding repoint and source delete.

[grantfitzsimmons]

@urban011 Please go ahead and send us the database using the instructions linked above. Please also send us the pre-repair snapshot and audit log extracts!

Our team is still investigating this. In the meantime, could you let us know if you have any database triggers or custom modifications?

[grantfitzsimmons]

@melton-jason will investigate before the end of next week: https://specifysoftware.bolddesk.com/agent/tickets/1281

[urban011]

Jason's #8469 fits our incident better than the merge hypothesis I posted on Aug 24. Consider that superseded. Corroboration from our database:

The rank profile matches exactly. All 8,631 affected determinations were at genus level or above, nearly all Family and higher (127 families, 58 orders, 16 classes; the full breakdown is in the issue body). Nothing determined below genus was touched. That's what rank-scoped batch edit predicts and what no other explanation accounted for.

workbench.0006_batch_edit arrived in our 2025-08-28 migration set. The damage started the next morning.

The spdataset id sequence jumps from 70 (2025-07-25) to 704 (2025-10-02), about 630 datasets created and deleted spanning the main damage window. That's why the event day shows no surviving dataset.

Later damage dates line up with surviving batch-edit datasets: our 2026-06-22 losses stamp 12:16:37, and dataset "All-Paleo-CollObj Mon Jun 22 2026" shows committed at 12:16:14. The 2026-05-31 losses follow a dataset committed 11:42 that day.

This also means no interrupted operation is required, so the worker-timeout interaction with #8064 I suggested is unnecessary for this bug.

[melton-jason]

Hi @urban011,

I did some looking into this Issue! Thank you for the database backup and exports of the Audit Log, they were very useful in narrowing down what the Issue was here.

Investigation into Tree Deletion and Merging

I don't think the Issue here is related to the deletion or merging of tree records.
Notably, tree deletion and tree merging are atomic in Specify: they are entirely already performed within transactions.

The deletion of a Tree node is handled the same as any other record within Specify: that is, the caller has to call the /api/specify/TABLE/ID/ endpoint with a DELETE request method. The handling of such a request flows through the following code on the backend:

specify7/specifyweb/specify/urls.py

Line 14 in 15a06a6

re_path(r'^specify/(?P<model>\w+)/(?P<id>\d+)/$', views.resource), # permissions added

specify7/specifyweb/specify/views.py

Line 78 in 15a06a6

resource = api_view(resource_dispatch)

specify7/specifyweb/specify/api/dispatch.py

Lines 62 to 76 in 15a06a6

	elif request.method == 'DELETE':
	if model.lower() == 'discipline' and not request.specify_user.is_admin():
	return HttpResponseForbidden('Specifyuser must be an institution admin')
	# Block deleting currently logged collection
	if model.lower() == 'collection' and int(id) == request.specify_collection.id:
	raise BusinessRuleException(
	"You cannot delete the collection you are currently logged into."
	)
	delete_resource(request.specify_collection,
	request.specify_user_agent,
	model, id, version)
	resp = HttpResponse('', status=204)

specify7/specifyweb/specify/api/crud.py

Lines 457 to 458 in 15a06a6

	@transaction.atomic
	def delete_resource(collection, agent, name, id, version) -> None:

The entire deletion operation is handled within a transaction, thanks to the @transaction.atomic decorator.
If you're unfamiliar with the decorator, it is a Django built-in and more information can be found at https://docs.djangoproject.com/en/4.2/topics/db/transactions/#controlling-transactions-explicitly.

Similarly, consider the path for tree merging:

specify7/specifyweb/backend/trees/urls.py

Line 11 in 383e28c

path('<int:id>/merge/', views.merge),

specify7/specifyweb/backend/trees/views.py

Lines 323 to 324 in 15a06a6

	@tree_mutation
	def merge(request, tree: TREE_TABLE, id: int):

specify7/specifyweb/backend/trees/views.py

Lines 56 to 69 in 15a06a6

	def tree_mutation(mutation):
	@login_maybe_required
	@require_POST
	@transaction.atomic
	@wraps(mutation)
	def wrapper(*args, **kwargs):
	try:
	mutation(*args, **kwargs)
	result = {"success": True}
	except BusinessRuleException as e:
	result = {"success": False, "error": str(e)}
	return HttpResponse(toJson(result), content_type="application/json")
	return wrapper

Thus, tree merging is also already entirely handled within a transaction.

While the static analysis indicated the problem didn't lie with tree deletion or merging, I also did some practical testing to verify the transactions would appropriately rollback in the case either operation didn't succeed.

To test record deletion, I performed the following specific test:

1. Locate a Taxon node at a relatively low level in the tree-- we will denote this Taxon node as A
   a. With my testing, a Taxon node at the Species level was sufficient
2. Locate an ancestor of A that is sufficiently high up in the tree-- we will denote this Taxon record as B
   a. For my testing, I used the Animalia node at the Kingdom level
3. Ensure that A does not have any delete blockers, and that no record directly or indirectly (through CASCADE relationships) references A
4. Send a DELETE request for Taxon B
5. Immediately after sending the delete request, start a concurrent process which will introduce a reference to A
   a. In my testing, I created a Determination record on a CollectionObject which referenced B through the taxon and preferredTaxon relationships

In every run of the above test, the delete operation performed on step 4 would error out with an error like the following:

django.db.models.deletion.ProtectedError: ("Cannot delete some instances of model 'Taxon' because they are referenced through protected foreign keys: 'Taxon.parent'.", {<Determination: Determination object (251406)>})

determination_referenced_logs.txt

There was no inserted Audit logs for the failed record deletion of B or for any of its descendants. Likewise, there were no side effects of the deletion present in the database after the deletion.

For both tree merging and deletion, I also performed a similar test:

1. Locate a Taxon node (A)
2. Locate another Taxon node (B)
3. Ensure that either or both of A and B are sufficiently "large" enough such that a record deletion or merging operation can be reasonably interrupted once started
4. Initiate a deletion of A or B, or initiate a merge of A -> B or B -> A
5. Kill the Specify and/or Database Manager (MariaDB) process while the operation is being performed
6. Inspect the Audit Log for any recorded operations, as well as counts of related records (such as Determination -> taxon or Determination -> preferredTaxon)

In every test, there were no inserted Audit Log records or resulting side effects from the interrupted process.

Tree record deletion or merging should also never result in the observed inserts of the Audit Log.

Specifically, there is only 4 places within Specify that will insert an UPDATE action into the Audit Log.
Two of these places are when a Loan Preparation is returned:

specify7/specifyweb/backend/stored_queries/execution.py

Lines 747 to 850 in dc429ec

	def return_loan_preps(collection, user, agent, data):
	spquery = data["query"]
	commit = data["commit"]
	tableid = spquery["contexttableid"]
	if not (tableid == Loanpreparation.specify_model.tableId):
	raise AssertionError(
	f"Unexpected tableId '{tableid}' in request. Expected {Loanpreparation.specify_model.tableId}",
	{
	"tableId": tableid,
	"expectedTableId": Loanpreparation.specify_model.tableId,
	"localizationKey": "unexpectedTableId",
	},
	)
	with models.session_context() as session:
	model = models.models_by_tableid[tableid]
	field_specs = fields_from_json(spquery["fields"])
	query, __ = build_query(session, collection, user, tableid, field_specs)
	lrp = orm.aliased(models.LoanReturnPreparation)
	loan = orm.aliased(models.Loan)
	query = query.join(loan).outerjoin(lrp)
	unresolved = (
	sql.functions.coalesce(model.quantity, 0)
	- sql.functions.coalesce(sql.functions.sum(lrp.quantityResolved), 0)
	).label("unresolved")
	query = query.with_entities(
	model._id, unresolved, loan.loanId, loan.loanNumber
	).group_by(model._id)
	to_return = [
	(lp_id, quantity, loan_id, loan_no)
	for lp_id, quantity, loan_id, loan_no in query
	if quantity > 0
	]
	if not commit:
	return to_return
	with transaction.atomic():
	for lp_id, quantity, _, _ in to_return:
	lp = Loanpreparation.objects.select_for_update().get(pk=lp_id)
	was_resolved = lp.isresolved
	lp.quantityresolved = lp.quantityresolved + quantity
	lp.quantityreturned = lp.quantityreturned + quantity
	lp.isresolved = True
	lp.save()
	auditlog.update(
	lp,
	agent,
	None,
	[
	FieldChangeInfo(
	field_name="quantityresolved",
	old_value=lp.quantityresolved - quantity,
	new_value=lp.quantityresolved,
	),
	FieldChangeInfo(
	field_name="quantityreturned",
	old_value=lp.quantityreturned - quantity,
	new_value=lp.quantityreturned,
	),
	FieldChangeInfo(
	field_name="isresolved",
	old_value=was_resolved,
	new_value=True,
	),
	],
	)
	new_lrp = Loanreturnpreparation.objects.create(
	quantityresolved=quantity,
	quantityreturned=quantity,
	loanpreparation_id=lp_id,
	returneddate=data.get("returneddate", None),
	receivedby_id=data.get("receivedby", None),
	createdbyagent=agent,
	discipline=collection.discipline,
	)
	auditlog.insert(new_lrp, agent)
	loans_to_close = (
	Loan.objects.select_for_update()
	.filter(
	pk__in={loan_id for _, _, loan_id, _ in to_return},
	isclosed=False,
	)
	.exclude(loanpreparations__isresolved=False)
	)
	for loan in loans_to_close:
	loan.isclosed = True
	loan.save()
	auditlog.update(
	loan,
	agent,
	None,
	[
	{
	"field_name": "isclosed",
	"old_value": False,
	"new_value": True,
	},
	],
	)
	return to_return

Another action which inserts an UPDATE action into the Audit Log is when sending a PUT (and sometimes POST¹) request to an /api/specify/TABLE/ID/ endpoint:

specify7/specifyweb/specify/api/crud.py

Line 147 in dc429ec

auditlog.update(obj, agent, parent_obj, dirty)

And finally, changes to records made in Batch Edit are logged:

specify7/specifyweb/backend/workbench/upload/upload_table.py

Line 1127 in dc429ec

self.auditor.update(reference_obj, None, dirty_fields)

Deleting any Specify record will not log individual field updates. Realisticaly, the only field updates that are possible when deleting a Specify record are any CASCADE deletions through relationhips: e.g., deleting a Preparation/Determination when its parent CollectionObject is deleted, deleting a Child Taxon record because its parent was deleted, etc.
Currently, CASCADE deletions are not logged (that is, only the "parent" record's deletion is logged): see related #8455.

When merging two tree nodes, Specify logs the Merge but does not log any direct or indirect update or deletions caused by that merge (see related #7388).
The merge functionality (for v7.12.0.7) in the backend is provided below, and static analysis shows the only audits are preformed through the mutation_log call to document the merge itself:

specify7/specifyweb/backend/trees/extras.py

Lines 325 to 388 in 383e28c

	def merge(node, into, agent):
	from specifyweb.specify import models
	logger.info('merging %s into %s', node, into)
	model = type(node)
	if not type(into) is model: raise AssertionError(
	f"Unexpected type of node '{into.__class__.__name__}', during merge. Expected '{model.__class__.__name__}'",
	{"node" : into.__class__.__name__,
	"nodeModel" : model.__class__.__name__,
	"operation" : "merge",
	"localizationKey" : "invalidNodeType"})
	target = model.objects.select_for_update().get(id=into.id)
	if not (node.definition_id == target.definition_id): raise AssertionError("merging across trees", {"localizationKey" : "operationAcrossTrees", "operation": "merge"})
	if into.accepted_id is not None:
	raise TreeBusinessRuleException(
	f'Merging node "{node.fullname}" with synonymized node "{into.fullname}"',
	{"tree" : "Taxon",
	"localizationKey" : "nodeOperationToSynonymizedParent",
	"operation" : "Merging",
	"node" : {
	"id" : node.id,
	"rankid" : node.rankid,
	"fullName" : node.fullname,
	"parentid": node.parent.id,
	"children": list(node.children.values('id', 'fullname'))
	},
	"synonymized" : {
	"id" : into.id,
	"rankid" : into.rankid,
	"fullName" : into.fullname,
	"parentid": into.parent.id,
	"children": list(into.children.values('id', 'fullname'))
	}})
	target_children = target.children.select_for_update()
	for child in node.children.select_for_update():
	matched = [target_child for target_child in target_children
	if child.name == target_child.name and child.rankid == target_child.rankid]
	if len(matched) > 0:
	merge(child, matched[0], agent)
	else:
	child.parent = target
	child.save()
	for retry in range(100):
	try:
	id = node.id
	node.delete()
	# Seems like this is done for the audit log. Why not log first, and then delete?
	# That way, we don't need to set the ID like below (quite a hack.)
	node.id = id
	mutation_log(TREE_MERGE, node, agent, node.parent,
	[FieldChangeInfo(field_name=model.specify_model.idFieldName, old_value=node.id, new_value=into.id)])
	return
	except ProtectedError as e:
	""" Cannot delete some instances of TREE because they are referenced
	through protected foreign keys: 'Table.field', Table.field', ... """
	regex_matches = re.finditer(r"'(\w+)\.(\w+)'", e.args[0])
	for match in regex_matches:
	related_model_name, field_name = match.groups()
	related_model = getattr(models, related_model_name)
	assert related_model != model or field_name != 'parent', 'children were added during merge'
	related_model.objects.filter(**{field_name: node}).update(**{field_name: target})
	assert False, "failed to move all referrences to merged tree node"

Tracking down the real culprit: Batch Edit

After having ruled out Tree record deletion and merging and knowing the possible paths for UPDATEs in the Audit Log, I suspected that BatchEdit might be the culprit here.
I inspected all BatchEdit Data Sets in the copy of the database sent to support and did not immediately find any Data Sets that would result in the extent of damages documented from #8434 (comment).

However, I did notice that deletion of WorkBench and BatchEdit Data Sets would not be logged in the Audit Log-- so it is possible the BatchEdit Data Sets were removed. See #8470.

P.S. You confirmed this hypothesis in your above comment: #8434 (comment)!

I inspected a complete export of the Audit Log, looking for audits before a Determination's taxon is removed to help determine what caused the change.

In all cases of where a Taxon was removed from a Determination, I found something like the following:

logId,action,parentRecordId,parentTable,recordId,table,fieldName,newValue,oldValue,timestamp
2290304,UPDATE,,,96,Spquery,,,,2025-08-29 08:40:26
...
2290324,INSERT,96,Spquery,3154,Spqueryfield,,,,2025-08-29 08:40:26
...
2290325,REMOVE,96,Spquery,3114,Spqueryfield,fieldname,,catalogNumber,2025-08-29 08:40:26
...
2290346,UPDATE,294912,Collection,10699,Determination,taxon_id,,78448,2025-08-29 08:50:42
2290347,UPDATE,294912,Collection,10706,Determination,taxon_id,,78607,2025-08-29 08:50:42

For all cases where a Taxon was removed from a Determination, a Query was created and subsequently deleted.
This leads me to beleive that a Query was made for the purposes of Batch Edit and deleted once the Batch Edit Data Set was created.
After the Query is deleted, the next entries in the Audit Log are the changes from the Batch Edit Commit.

I reconstructed the Queries from the Audit Log where the Taxon had been removed from a CollectionObject's Determination and worked with different records in the database to recreate the Issue.

After some investigation, I uncovered the root cause of this Issue:

Batch Edit would silently unlink Tree relationships if their ranks were not included in the BatchEdit Data Set.
For example if a CollectionObject is determined to a Family taxon and only Genus and lower ranks are present in the Query used for BatchEdit, then the record would have no data for the fields in the Data Set and Specify would think the user intends to unlink the Determination from the Taxon.

I have created an Issue to document this behavior: #8469

Footnotes

1. POST requests log UPDATEs in the Audit Log if an indpendent record through a relationship is updated as part of the record creation. For example, updating an existing CollectionObject when creating an Accession ↩