Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Search docs: still warns about ES aliasing, but referenced bug appears fixed

See original GitHub issue

The docs for ATOMIC_REBUILD say:


This option may not work on Elasticsearch version 5.4 and above, due to a bug in the handling of aliases affecting these releases.

But appears to fix that issue, and the fix looks to be in >=5.5 - see

So I think that this warning is wrong, and that the issue may only affect version 5.4, and that the warning may be incorrectly guiding people away from using ATOMIC_REBUILD with recent versions of Elasticsearch.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:7 (4 by maintainers)

github_iconTop GitHub Comments

gasmancommented, May 7, 2020

Thanks for the detective work! That sounds like a very plausible explanation of the problems seen on 5.6.3 in #3985 - will go ahead and update the note now.

plumdogcommented, May 6, 2020

@gasman So I can’t make update_index fail.


Comparing the code for the ES search backend between current master and, I spotted a change that I think might explain why:

This change was introduced in which fixed the usage of the ES client (because positional arguments changed order in ES Python client 1.7.0).

So I think that anyone using Wagtail without the #4128 fix, which is to say anything not >=2 or >=1.13.2 or >= 1.12.4 and using ES Python client >=1.7.0 would have had broken ATOMIC_REBUILD.

That would explain #3985 (given as “Wagtail Version 1.13”, but opened Oct 31st 2017, and fix didn’t go into 1.13 until Dec 14th 2017, so some unfixed 1.13 version), and “Elasticsearch PY Version: 5.4.0”, so would have had the broken behaviour that #4128 fixed.

Then as for why as of #3637 (June 7th 2017) you saw misbehaving ATOMIC_REBUILD behaviour, I wonder whether it was because this would have always failed on ES 5.4, because the bug means this always returns True.

Against my test bed, using ES 5.4.2:

>>> from elasticsearch import Elasticsearch
>>> es = Elasticsearch(hosts=['elasticsearch'])
>>> some_index ='json')[0]['index']
>>> print(some_index)
>>> es.indices.exists_alias(name='doesnotexist', index=some_index)

which is lies, and would break that test. But on ES 5.5.2:

>>> from elasticsearch import Elasticsearch
>>> es = Elasticsearch(hosts=['elasticsearch'])
>>> some_index ='json')[0]['index']
>>> print(some_index)
>>> es.indices.exists_alias(name='doesnotexist', index=some_index)

So I think that the tests failed because the assertions about whether or not aliases existed were getting lies from ES because of the ES 5.4 bug.

Which is all an extremely long-winded way of saying, if you are using:

  • a Wagtail released after Feb 2018 (>=2, >=1.13.2, >= 1.12.4)
  • an Elasticsearch released after July 2017 (!= 5.4.x)

then ATOMIC_REBUILD will work fine. And in fact, I think that a recent Wagtail on ES 5.4 might actually cope OK (at least, I couldn’t break it). But given it definitely does use the “check if alias for index exists” that will be getting lies from ES, so I think it is probably safest to say “ES 5.4 not supported for ATOMIC_REBUILD”.

So I think that means - thanks to #4128 - the issue really is at worst confined to ES 5.4, and the warning should say as much.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Common problems | APM Server Reference [7.15] - Elastic
This error occurs when APM Server attempts to write to an index instead of an alias. One way this can happen, is when...
Read more >
Troubleshoot creatives rejected by Display & Video 360 or ...
Looking for a specific rejection code you saw in Display & Video 360? To search for it on this page, press Ctrl +...
Read more >
Bug listing with status RESOLVED with resolution FIXED as at ...
Bug listing with status RESOLVED with resolution FIXED as at 2022/12/17 06:46:03.
Read more >
Directives - Sphinx documentation
Consider this example (taken from the Python docs' library reference index): ... This will still notify Sphinx of the document hierarchy, but not...
Read more >
Hibernate Search 6.1.7.Final: Reference Documentation
The problem, which is not limited to just Hibernate Search, has been reported, but hasn't been fixed yet in Spring Boot 2.5.1.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found