Upgrade fails on failure to update reference data

By using the UI or the APIs (that is, in sanctioned ways) it is possible to create user data that conflicts with incoming reference data on module upgrade.

This conflict causes loading reference data to fail.

This failure aborts the entire upgrade. Okapi continues to route to the original (un-upgraded) module set for the tenant.

The storage module schemas, however, may have been fully or partially upgraded, so system storage may be left in an inconsistent state. It is likely impossible to know the state of the system storage without Okapi logfile analysis and module code inspection.

There are a few ways to address this, from fairly simple to quite complex:

• Modules could log a failure to load reference data as a warning or error in the log, but still respond to the tenant initialization request with a success or partial-success error code.
• Okapi could respond to the tenant install call with a status of something like "enabled with warnings" and (ideally) a message in the install API response.
• Modules could adopt a more precise and nuanced approach to managing reference data. For example, reference data could be treated as immutable, and protected from updates either using the UI or the API.
• Modules could adopt a layered approach to reference data management, as proposed in https://wiki.folio.org/display/SYSOPS/Upgrades+with+Reference+data

This issue was created to address the immediate concern of upgrade failure leaving a system in an inconsistent state.

See also

• Improved Handling of Reference Data During Upgrades
• Settings - Reference data decisions and load sequence for migration