Partial fix XFES fails to delete a readonly index

[Xon]

Affected version

2.2.0

When XFES rebuilds an index, it deletes the entire index, creates it and then applies the type mapping. The delete process can fail if the index has been set into read-only mode, which can happen in low-disk space and some other cases.

It would be useful if XFES gave a useful error message on attempting to delete a read-only index, or just silently enabled per-index deleting of read-only indexes before deleting it.

As is, this sort of thing can be done via CLI but it is a little challenging to figure this out.

curl -XPUT 'localhost:9200/<_index>/_settings' -H 'Content-Type: application/json' -d '{
    "index": {
        "blocks": {
            "read_only_allow_delete": "false"
        }
    }
}'

 

[Mike]

I'm reticent to make any changes here based on what you're suggesting. Based on the docs, read_only_allow_delete should still allow the index to be deleted. If the index has been set to read_only, then the delete would fail, but that would presumably be expected on the basis of that block being set explicitly. Presumably Elasticsearch should be returning a reasonable error in this case, though I have to confirm that.

Are you actually reporting an issue with the new index being created when Elasticsearch has set read_only_allow_delete to true? If so, that makes more sense and it's probably a flag that we shouldn't try to maintain when recreating the index.

 

[Xon]

I've occasionally got it stuck where XenForo essentially refuses to touch ElasticSearch, and recovery is very non-obvious

Are you actually reporting an issue with the new index being created when Elasticsearch has set read_only_allow_delete to true? If so, that makes more sense and it's probably a flag that we shouldn't try to maintain when recreating the index.

Yeah, once the index is in this state XenForo looks to try to create it in that state which is kinda silly.

 

[Mike]

Are you actually reporting an issue with the new index being created when Elasticsearch has set read_only_allow_delete to true?

I was able to reproduce this situation and I've adjusted it so that we don't maintain any blocks when we recreate the index. This is certainly an XF bug that I've now fixed. In my tests (which admittedly don't have ES flipping this flag automatically), this manifests after the next index has been created, when the index rebuild fails.

However, I'm not clear on whether this was what you were specifically reporting. I've manually put the index in read_only mode (which shouldn't be something that happens automatically). The index deletion does fail with an exception "XFES\Elasticsearch\RequestException: index [index_name] blocked by: [FORBIDDEN/5/index read-only (api)]" though I think I'd consider that more or less expected. It's an exceptional condition from our perspective, generally like most MySQL issues, and it isn't something that can be toggled from within XF.