https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Sponsorship status|Sponsored |Unsponsored -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 203177 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203177&action=edit Bug 43231: Don't let a failed ES mapping update abort the DB upgrade The atomic update for bug 40658 (making local-number sortable) calls Koha::SearchEngine::Elasticsearch::Indexer->update_mappings() directly whenever Elasticsearch is enabled. If the existing index already has local-number mapped as a plain integer (as it did before local-number was made sortable), Elasticsearch refuses the in-place mapping change: mapper [local-number] cannot be changed from type [integer] to [text] update_mappings() catches that internally and marks the index status as needing a full recreate/reindex, but it then re-throws, so the exception was left to propagate out of the atomic update and abort the whole schema upgrade - even though Elasticsearch was enabled and otherwise working fine, and even though the failure is a known, already-handled case. Wrap the call in try/catch so a mapping failure only produces a warning in the upgrade output, and the schema upgrade continues. The "index needs to be recreated" status set by update_mappings() is already surfaced by admin/searchengine/elasticsearch/mappings.pl and acted on by misc/search_tools/rebuild_elasticsearch.pl, so no extra plumbing is needed to alert admins or fix the index afterwards. Test plan: 1. On an instance with Elasticsearch enabled and biblios indexed, force local-number's mapping to a non-sortable type, e.g.: PUT /koha_kohadev_biblios/_mapping { "properties": { "local-number": { "type": "integer" } } } 2. Roll the DB version back before 25.12.00.059 and re-run updatedatabase.pl (or koha-upgrade-schema) so it re-applies this revision. 3. Without this patch: the upgrade aborts with the Koha::Exception above and no later DB revisions are applied. 4. With this patch: the upgrade prints a warning and continues; later revisions still apply. admin/searchengine/elasticsearch/mappings.pl shows the biblios index as needing to be recreated. 5. Run misc/search_tools/rebuild_elasticsearch.pl -r -b to fix the index, confirm the warning clears. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Setting Version to 25.11 as it's especially problematic at that point.. but it'll need applying to all branches 25.11 upwards -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43231 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Bug 40658 breaks CLI for |Bug 40658 still breaks CLI |25.11 |for 25.11 after Bug 42795 -- You are receiving this mail because: You are watching all bug changes.