[
https://issues.apache.org/jira/browse/UNOMI-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095513#comment-18095513
]
Serge Huber commented on UNOMI-465:
-----------------------------------
h2. Re-targeted to unomi-3.2.0
Moved fixVersion from {{unomi-3.1.0}} to {{unomi-3.2.0}}.
When Elasticsearch or OpenSearch enters index read-only mode (e.g. disk
watermark), Unomi can fail to persist events/rules/segments while clients still
see success — there is no unified detection or HTTP 422 signalling on write
paths today. This remains a valid *Critical* ops concern.
Implementing it properly requires cluster-block detection in *both* persistence
backends and consistent error mapping across REST/context/GraphQL — too large
to hold 3.1.0 GA. Scheduled as early 3.2 work.
h2. Mitigation for 3.1
* Monitor cluster health externally and via the {{healthcheck}} extension
(ES/OS provider).
* Alert on disk watermarks and cluster {{red}} / read-only blocks before Unomi.
* Do not rely on event POST returning 200 as proof of durable indexing during
cluster incidents.
> Unomi stops saving events when elastic enters readOnly mode. No way to see
> that something is wrong on client side.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: UNOMI-465
> URL: https://issues.apache.org/jira/browse/UNOMI-465
> Project: Apache Unomi
> Issue Type: Bug
> Components: unomi(-core)
> Affects Versions: unomi-1.5.4
> Reporter: Risto Kowaczewski
> Priority: Critical
> Fix For: unomi-3.2.0
>
>
> I encountered the following error. When elasticsearch server has very little
> disk space it can go into read-only mode. Then it stops saving data. But
> there is no way the client (GUI, etc) knows that there is a problem.
> If you do not monitor elastic then you can go days without data being saved.
> I guess I will have to monitor elastic from GUI to alert users that something
> is not ok.
> This happens also when you create rule, segment, etc.
> Suggested approach is to use HTTP protocol as it is. And return data as it is
> but insted of 200 code return: 422 Unprocessable Entity.
> 422 Unprocessable Entity response status code indicates that the server
> understands the content type of the request entity, and the syntax of the
> request entity is correct, but it was unable to process the contained
> instructions.
> Using this approach will ensure that context server and the rest of unomi
> works but it indicates that there is something wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
