What is a one sentence summary of your feature request?
Enable GroupID to gracefully handle Elasticsearch storage issues through proactive alerts, fallback data logging, and user interaction prompts to prevent data loss during partial system failures.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
When Elasticsearch enters a read-only state due to disk constraints, historical data logging fails silently, resulting in lost audit trails and user confusion. The real need is a more resilient and interactive approach, and there shouldn’t be any data loss at all. Directory manager should save the data in one of the repositories at least.
Introduce user prompts/warnings when dependencies like Elastic are down, save failed history logs to a fallback or retry queue, and provide the user with a choice to continue or delay the operation.
How do you currently solve the challenges you have by not having this feature?
Today, if Elastic becomes read-only, no historical data is recorded, and there’s no immediate alert unless manually monitored. Actions may still succeed in systems like AD, but without user awareness of logging failure, this leads to confusion and unrecoverable data gaps. Workarounds include elasticsearch health reporter utility, manual log checks or external monitoring, neither of which is reliable or scalable for enterprise operations.