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: [email protected]
          Reporter: [email protected]
        QA Contact: [email protected]
                CC: [email protected]
  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.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to