PDF Report Cannot Be Generated

Log Analysis

If the generation of a PDF report fails with the generic error message "The report could not be created.", more information about the error can usually be found in the logs.

Cadenza Server Logs

In addition to possible exceptions thrown by the Java code (in Cadenza or the Selenium library), the following special sections can be found in the log if a report fails:

  • Browser logs: The browser console output of the Chromium instance used to render the report. This log is enabled by default for every failed report. If the log level of net.disy.cadenza.workbook.webreport.webdriver.WebDriverService is set to "TRACE", it is also logged on successful report creation.

  • Chromium Network logs: All network requests triggered by the report page (roughly the equivalent of the "Network" tab in the Chrome Dev Tools). This log is enabled for failed reports if the log level of net.disy.cadenza.workbook.webreport.webdriver.WebDriverService is at least "DEBUG". If the log level is set to "TRACE", it is also logged on successful report creation.

  • Content of the report HTML page: The complete HTML source of the report page. This log is disabled by default. Is logged when the report generation times out while waiting for the report page to load, if the log level of net.disy.cadenza.workbook.webreport.webdriver.WebDriverService is set to "TRACE".

Common errors:

Tab crashed
org.openqa.selenium.WebDriverException: unknown error: session deleted because of page crash
from unknown error: cannot determine loading status
from tab crashed

This usually means that the report is too big for Chromium to handle and it ran out of memory. For information about how to increase the memory available to Chromium (up to a certain limit), see Exporting PDF Reports.

Report Generator Logs

The logs of the report generator that acts as an intermediator between Cadenza and the browser are disabled by default.

You can configure that they are logged into a file on the system where the report generator runs. It is not possible to include these logs into the Cadenza server log.

The report generator logs are turned on by passing the following system property to Cadenza:

  • -Dwebdriver.chrome.logfile=<path to chromedriver logfile (including the file name)>

    This parameter must point to a path for which the user running Cadenza has write permissions. Otherwise, it may cause the report generator to crash.

The log output can be fine-tuned further with the following properties:

  • -Dwebdriver.chrome.appendLog=true
    Append the report generator logfile instead of overwriting it with each initialization.

  • -DcadenzaChromeDriverLogLevel=[ALL | INFO | DEBUG | WARNING | SEVERE | OFF]
    Sets the log level of the report generator.

  • -Dwebdriver.chrome.verboseLogging=true
    Set the log level of the report generator to the highest possible ("ALL").

  • -Dwebdriver.chrome.silentOutput=true
    Reduce logging to a minimum. Might be useful to get rid of errors and warnings that are not really a problem. But use with caution. If there is an actual problem, the error could be hidden.

Debugging with the Docker container selenium/standalone-chrome

When using the selenium/standalone-chrome Docker container instead of the report generator installed with Cadenza, the system property cadenzaChromeDriverLogLevel does not have any effect. The rest of the system properties work there, too.

They have to be added to the SE_JAVA_OPTS environment variable of the container.

Increase Log Level of Selenium Server

You can increase the log level of the Selenium Server by adding the following to the environment variable SE_OPTS: --log-level ALL

Selenium UI

If a report is stuck, it can be useful to have a look at the queue of the Selenium container. You can do that in a web UI. Just use the URL configured in workbookreport-config.xml in <remoteWebDriverUrl> with the added suffix "/ui".

If the container is deployed in Kubernetes, there must be an ingress configured that is reachable from outside the cluster.