https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=44023

            Bug ID: 44023
           Summary: es_indexer_daemon.pl never recognises NoNodes: the
                    check added in bug 42669 can never match
   Initiative type: ---
        Sponsorship ---
            status:
           Product: Koha
           Version: Main
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Searching - Elasticsearch
          Assignee: [email protected]
          Reporter: [email protected]
        QA Contact: [email protected]
  Target Milestone: ---

Bug 42669 added a retry for the case where Elasticsearch cannot be reached:
when the
indexing fails with NoNodes the daemon logs "Elasticsearch unavailable
(NoNodes),
resetting jobs for retry" and sets the jobs back to 'new'.

The follow-up from QA tests the error with

    ref($_) eq 'Search::Elasticsearch::Error::NoNodes'

but Koha::SearchEngine::Elasticsearch::Indexer::update_index() catches every
Search::Elasticsearch error and rethrows it as a
Koha::Exceptions::Elasticsearch::BadResponse, with the original class in
->type. The
exception the daemon catches is therefore never a NoNodes object, the check
never
matches, and an unreachable Elasticsearch ends with the jobs marked 'failed'
and the
updates lost. The retry added by 42669 never runs.

The worker log shows it:

    Update of elastic index failed with: Exception
    'Koha::Exceptions::Elasticsearch::BadResponse' thrown 'Bad response
received when
    submitting request to Elasticsearch' with details => No nodes are
available:
    [http://...], type => NoNodes

The first version of the patch for 42669 matched the stringified exception,
which
contains "type => NoNodes", and worked. The change to ref() broke it.

The patch checks the type of the BadResponse as well (the plain class check is
kept for
code paths that let the raw error through).

Note: the retry only helps when JobsNotificationMethod is polling. With STOMP
the message
is acknowledged before commit() and the daemon only reads the table in polling
mode, so a
job reset to 'new' is never picked up again. That needs a separate change (see
the bug
about retrying the batch in the worker).

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to