records: make do_finalise
more robust and tolerate multiple commit messages
#761
Labels
do_finalise
more robust and tolerate multiple commit messages
#761
A problem was recently reported with version 2 of a record which failed to display because of multiple (10!) entries in the
record_version_commit_message
database table with the samerecid
andversion
. There were new Sentry events:MultipleResultsFound: Multiple rows were found when exactly one was required
from the line:hepdata/hepdata/modules/records/api.py
Line 327 in ef2ea51
This situation could conceivably arise if
do_finalise
fails (for example, due to problems connecting to the database) after the commit message has been added to the database, but before settinghep_submission.overall_status = "finished"
. Eventually, after 10 duplicate commit messages had been added, it seems that thedo_finalise
function failed when reindexing.The
do_finalise
function should be made more robust to catch possible exceptions due to temporary problems connecting to the database or OpenSearch, for example, by usingdb.session.rollback()
to rollback changes to the database and by catching reindexing exceptions (similar to thetry
/except
used for theadmin_indexer
immediately below). An exception should return an error to the user requesting that they try to finalise the record later. This is better than partially finalising the record with some steps missing.Although it should not happen, the
get_commit_message
function could also be made more robust to tolerate multiple commit messages with the samerecid
andversion
, for example, by replacing the lines:hepdata/hepdata/modules/records/api.py
Lines 323 to 327 in ef2ea51
with:
to get the most recent commit message in case there are multiple entries in the database.
The text was updated successfully, but these errors were encountered: