Incorrectly configured search backend breaks page publishing (URLS always has to be a list)

Issue Summary

I ran into this issue that is probably more a quality of life thing.

Steps to Reproduce

1. Have a search backend configured with (as I eventually deduced), URLs set to a single value and not a list. Example:

if "ELASTICSEARCH_HOST" in os.environ:
    WAGTAILSEARCH_BACKENDS["elasticsearch"] = {
        "BACKEND": "wagtail.search.backends.elasticsearch7",
        "URLS": os.environ["ELASTICSEARCH_HOST"],
        "AUTO_UPDATE": True,
        "ATOMIC_REBUILD": True,
    }

In this case what I was fulling was a single host url: http://elasticsearch:9200 2. Try to save a page, or even a draft of a page 3. Wagtail explodes: https://dpaste.com/FA8FKYRS3

It took me awhile to trace through and find where the host was missing as the error message really doesn’t point you in the right direction.

I think the problem may only be with Elasticsearch, but I haven’t tried other backends.

The doc examples are clear and always show URLS wrapped as a list. But my instinct if I have a single value is not to cast it to a list.

At the very least a note in the docs might help. Even better would be catching the error and deciding how to recover a bit more gracefully and pointing at the problem.

Best would be to handle this a bit better. I think the code is here: https://github.com/wagtail/wagtail/blob/8251b4a6c7e1660e16e721a9f45669986a2699a4/wagtail/search/backends/elasticsearch2.py#L1070

I think we could do a simple check. Say, if the item is a list, or cast it to a list if not. Now there could be complications with that, obviously, which is why this is just a bug report so far and not a fix. 😄 Short of that, we should be able to check if the value is a list and raise an error if not.

• I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: no

Technical details

• Python version: 3.8
• Django version: 3.1.1
• Wagtail version: 2.10
• Browser version: Chrome 85

[gasman]

I think it’s possible to get too clever with things like that. Ultimately the URL entered there will be handed to the Elasticsearch library, so it’s not really Wagtail’s job to determine its validity, any more than it’s Wagtail’s job to recover from Python syntax errors in user code. If, say, Elasticsearch happens to support a URL scheme that allows comma characters, then it would be counter-productive for Wagtail to pre-empt that and guess that the user intended to pass a list of URLs.

[easherma]

@gasman I agree. Looking back I see the stacktrace I pasted didn’t appear to persist, but it took me awhile to pore through it and figure out what actually happened, and it might have taken someone else longer. I ideally wouldn’t expect the entire app to crash with a ‘host name not specified’ error (recalling from memory what exactly it said, but at least a more graceful error pointing more clearly to the source of the problem.

Hope that makes sense! It’s definitely a finely split hair, and not likely to be a big persistent issue so I’m trying not to make to big a deal out of it. 😃