https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42994 Bug ID: 42994 Summary: Atomic update for Bug 40658 (local-number sortable) fails on Zebra-only installations Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs@lists.koha-community.org Reporter: dghdghfghfgh04@gmail.com QA Contact: testopia@bugs.koha-community.org CC: tomascohen@gmail.com Target Milestone: --- The atomic update script that implements Bug 40658 ("Ensure local-number is sortable"), located at installer/data/mysql/db_revs/251104011.pl (25.11.x) / equivalent on main, unconditionally instantiates the Elasticsearch indexer and calls update_mappings(), regardless of the SearchEngine system preference: my $index_name = $Koha::SearchEngine::Elasticsearch::BIBLIOS_INDEX; my $indexer = Koha::SearchEngine::Elasticsearch::Indexer->new( { index => $index_name } ); $indexer->update_mappings(); On a Zebra-only installation with no Elasticsearch server configured or running, this call fails, and koha-upgrade-schema / updatedatabase aborts partway through the atomic update with: ERROR: Exception 'Koha::Exception' thrown 'Unable to update mappings for index "koha_<instance>_biblios". Reason was: "". Index needs to be recreated and reindexed' accompanied by: Use of uninitialized value $reason in concatenation (.) or string at /usr/share/koha/lib/Koha/SearchEngine/Elasticsearch/Indexer.pm line 276. The "Reason was: ''" text and "Index needs to be recreated and reindexed" wording are misleading — they suggest a mapping conflict on an existing index. In practice, the failure occurs even when there is no Elasticsearch server reachable at all (verified via `ss -tlnp | grep 9200`, `curl` returning connection refused/000, and no elasticsearch systemd unit present). The root cause is that $reason in Indexer.pm (line 276) is never populated with the actual underlying error (connection failure, mapping conflict, or otherwise), so all failure modes are reported identically and misdirect troubleshooting toward index/mapping issues rather than connectivity. Steps to reproduce: 1. Set up or use an existing Koha instance with: - SearchEngine system preference = Zebra - No Elasticsearch server configured/running 2. Run koha-upgrade-schema <instance> (or updatedatabase.pl) up to/through the 40658 atomic update. 3. Observe the exception above; the upgrade halts. Expected behavior: The atomic update should check the SearchEngine system preference before attempting any Elasticsearch operations, e.g.: if ( C4::Context->preference('SearchEngine') eq 'Elasticsearch' ) { # existing ES mapping update logic } else { say_info($out, "Zebra in use: skipping Elasticsearch mapping update"); } The underlying database change (search_marc_to_field.sort = 1 for the local-number field) should still be applied regardless of search engine, since that part is search-engine-agnostic and succeeds independently of the ES call. Additionally, Indexer.pm line 276 should be fixed so that $reason is actually populated from the underlying exception/error, rather than being left uninitialized — this would have surfaced the real cause (connection failure) immediately instead of a misleading mapping-conflict message. Workaround used: 1. Manually verified and applied the DB-only change: UPDATE search_marc_to_field SET sort = 1 WHERE search_marc_map_id = <id for local-number/biblios/marc21>; 2. Patched the local copy of the atomic update script to skip the Elasticsearch call when SearchEngine != 'Elasticsearch'. 3. Re-ran the schema upgrade successfully. Note: this workaround needs to be reapplied after any package upgrade that overwrites the vendored atomic update script, until this is fixed upstream. Related: Bug 40658 (this report is about the atomic update script it introduced, not the local-number__sort fix itself, which is unrelated and working as intended). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.