MOAB_NOT_FOUND should probably be in the AuditResults::HONEYBADGER_REPORT_CODES list?

[jmartin-sul]

this seems like a serious and unexpected situation. we update the status on the CompleteMoab (complete_moabs entry) when this is detected, and we log it and send to workflow service and event service, but it appears that we don't proactively send a honeybadger alert.

discovered while working on #1480/#1481. tried just adding to the list, got some unexpected test failures around unexpected network requests. likely not a difficult fix, but didn't have the time to chase it down on thurs/fri of last week.

[jmartin-sul]

happy to close this if we did this intentionally, and i'm forgetting why

[ndushay]

Here's what I can think of:

• would we get a MOAB_NOT_FOUND when we're creating the first version of an object, which we wouldn't want to report to honeybadger??
• other situations related to the above case?

Also, is this PR relevant, which is about looking for a moab on a diff disk? PR #1271

[jmartin-sul]

Here's what I can think of:

* would we get a MOAB_NOT_FOUND when we're creating the first version of an object, which we wouldn't want to report to honeybadger??

in that case i think we'd get CREATED_NEW_OBJECT:

preservation_catalog/app/services/complete_moab_handler.rb

Lines 35 to 66 in af8beb9

	# checksums_validated may be set to true if the caller takes responsibility for having validated the checksums
	def create_after_validation(checksums_validated = false)
	results.check_name = 'create_after_validation'
	if invalid?
	results.add_result(AuditResults::INVALID_ARGUMENTS, errors.full_messages)
	elsif PreservedObject.exists?(druid: druid)
	results.add_result(AuditResults::DB_OBJ_ALREADY_EXISTS, 'PreservedObject')
	elsif moab_validation_errors.empty?
	creation_status = (checksums_validated ? 'ok' : 'validity_unknown')
	create_db_objects(creation_status, checksums_validated)
	else
	create_db_objects('invalid_moab', checksums_validated)
	end
	results.report_results
	end
	# checksums_validated may be set to true if the caller takes responsibility for having validated the checksums
	def create(checksums_validated = false)
	results.check_name = 'create'
	if invalid?
	results.add_result(AuditResults::INVALID_ARGUMENTS, errors.full_messages)
	elsif PreservedObject.exists?(druid: druid)
	results.add_result(AuditResults::DB_OBJ_ALREADY_EXISTS, 'PreservedObject')
	else
	creation_status = (checksums_validated ? 'ok' : 'validity_unknown')
	ran_moab_validation! if checksums_validated # ensure validation timestamps updated
	create_db_objects(creation_status, checksums_validated)
	end
	results.report_results
	end

preservation_catalog/app/services/complete_moab_handler.rb

Lines 188 to 210 in af8beb9

	def create_db_objects(status, checksums_validated = false)
	cm_attrs = {
	version: incoming_version,
	size: incoming_size,
	moab_storage_root: moab_storage_root,
	status: status
	}
	t = Time.current
	if ran_moab_validation?
	cm_attrs[:last_version_audit] = t
	cm_attrs[:last_moab_validation] = t
	end
	cm_attrs[:last_checksum_validation] = t if checksums_validated
	ppid = PreservationPolicy.default_policy.id
	# TODO: remove tests' dependence on 2 "create!" calls, use single built-in AR transactionality
	transaction_ok = with_active_record_transaction_and_rescue do
	PreservedObject
	.create!(druid: druid, current_version: incoming_version, preservation_policy_id: ppid)
	.complete_moabs.create!(cm_attrs)
	end
	results.add_result(AuditResults::CREATED_NEW_OBJECT) if transaction_ok
	end

i think we'd only get MOAB_NOT_FOUND if we were expecting to see it already.

* other situations related to the above case?

none i can think of 🤷‍♂️

Also, is this PR relevant, which is about looking for a moab on a diff disk? PR #1271

i think that was the "let C2M detect moved moabs" approach to storage migration. i could see turning off the MOAB_NOT_FOUND code if we went with that approach as-is, but i don't think that was the cause of this.

reasonable conjectures, but i'm guessing it was oversight at this point.