Repository navigation
Better messaging around reporting timeouts #17949
Description
Activity
Original comment by @ycombinator:
I'm not sure where the best place in code would be to emit this message (esqueue or reporting) but I think an ideal error message would be actionable for the user. I don't see why we couldn't just use your explanation from the description, so maybe something like:
Report generation timed out. Increase
xpack.reporting.queue.timeout(default: 30s) in your Kibana config and try again.Original comment by @ppf2:
I am adding a cloud tag to this. I just came across this in my cloud instance which I had a 30m-interval job for a report that would generally only take 2+ mins to generate (well, it still throws that 502 error which is a known issue with watcher integration, but at least the reporting generation will still complete successfully).
!LINK REDACTED
For whatever reason, it no longer completes and throw the generic max # of retries error. I just assume that my instance is being affected by noisy neighbors since I don't have anything else (or any other reporting job running on the instance).
Note that even if we change that message in reporting to the proposed "Report generation timed out. Increase xpack.reporting.queue.timeout (default: 30s) in your Kibana config and try again.", this will not help Elastic Cloud users because Elastic Cloud users currently do not have the ability to change Kibana yml configurations (so even if they have an explanation of the message above, it's not something they can fix on their own - LINK REDACTED) ...
Original comment by @ppf2:
+1 We certainly have customers running into this and not sure what to do about the max attempt reached message. It will be nice to provide more details with the error.
Many enhancements have gone to address this since this issue was filed:
- [Reporting] use data-test-subj on toast to check for failure #25482
- [Reporting] Better logging for waitForSelector failure #25762
- [Reporting] Enhance Error Messaging and Handling 3 #26299
- [Reporting] Fix error handling in process request failed #31861
These will change some types of failures from a timeout message to a more meaningful messages, and adds extra logging for the failures in general.
Original comment by @w33ble:
Currently, if the default
xpack.reporting.queue.timeoutisn't high enough (30s by default), and the worker times out, the job is eventually aborted and an error message is shown.!LINK REDACTED
It's not really clear to the user what the "Max attempts" message means though. The error itself is coming from esqueue, but if a clean, universal error message can't be found, Reporting could replace it with its own message instead.