Bibs transformer should report and not stop if legacy identifier not found

[banerjek]

Bibs transformer should log/skip records that lack an identifier. Current behavior can detonate a large build. In the case at hand, a single character typo when entering the number caused failure (legacy identifier is 997a, but a subfield marker at the beginning of the value caused the field to be considered empty):

2024-12-12 00:54:21,047 INFO    108.9 (avg. 111.3) records/sec.         600,000 records processed       bibs
2024-12-12 00:55:05,425 INFO    112.7 (avg. 111.3) records/sec.         605,000 records processed       bibs
Traceback (most recent call last):
  File "/home/ssm-user/client_data/migration_umlib/.venv/lib/python3.9/site-packages/folio_migration_tools/marc_rules_transformation/marc_file_processor.py", line 69, in process_record
    folio_recs = self.mapper.parse_record(marc_record, file_def, legacy_ids)
  File "/home/ssm-user/client_data/migration_umlib/.venv/lib/python3.9/site-packages/folio_migration_tools/marc_rules_transformation/rules_mapper_bibs.py", line 115, in parse_record
    folio_instance = self.perform_initial_preparation(marc_record, legacy_ids)
  File "/home/ssm-user/client_data/migration_umlib/.venv/lib/python3.9/site-packages/folio_migration_tools/marc_rules_transformation/rules_mapper_bibs.py", line 67, in perform_initial_preparation
    FolioUUID(
  File "/home/ssm-user/client_data/migration_umlib/.venv/lib/python3.9/site-packages/folio_uuid/folio_uuid.py", line 34, in __init__
    raise ValueError("Legacy Identifier not provided")
ValueError: Legacy Identifier not provided
2024-12-12 00:55:06,521 ERROR   <class 'ValueError'>    bibs
2024-12-12 00:55:06,521 ERROR   ('Legacy Identifier not provided',)     bibs
2024-12-12 00:55:06,522 ERROR   Legacy Identifier not provided  bibs
2024-12-12 00:55:06,522 ERROR   =LDR  01313cam a2200337 i 4500
=001  2877799
=005  20051019184804.0
=008  860401s1987\\\\at\a\\\\\b\\\\001\0\eng\\
=010  \\$a   86006737
=020  \\$a0731800311$qpaperback
=997  \\$a$86006737
=040  \\$aUMM$dUMP$erda

[bltravis]

@banerjek Interesting. How did that errant subfield indicator end up in the field?

[banerjek]

@bltravis My best guess is they were editing out of their system (i.e. in Marcedit) and compiled into MARC after accidentally entering another marker while in the field