Error while creating PDF with PDF Print Plugin

The action Create PDF (print service) has failed and the log shows request timed out as the cause of the error.

The following error message can be found in the log:

[ERROR] [2023-12-05T14:34:18.297+01:00] [36691f8a-5d57-4f31-8812-55d8270bedc8] console.error: Failed to load resource: net::ERR_CACHE_READ_FAILURE
  at https://my-server.de/formcycle/form/includes/ressource?name=XSignature.js&plguuid=f1530d6a-31e6-4ecb-94a9-53ea020f5982&pid=1006&_nc=1700131199094:0:0

This is an error that has also been occasionally seen on other systems. So far, it has only occurred on Windows servers with print service.

For explanation: The print service itself starts a Chromium browser in which the form is opened in order to generate a PDF file from the form. When the form is called up, CSS and JavaScript files must also be loaded. Browsers have a cache so that these files do not need to be downloaded each time.
The error message now means that the Chromium browser was unable to read its cache. As a result, the required JavaScript files cannot be loaded. This means that the form cannot be called up successfully and no PDF can be created.

The exact reason for the cause is difficult to pinpoint. It is possible, for example, that Windows or other cleanup programmes delete the cache files in the temp directory, which causes the next print attempt to fail.

The following options exist to prevent this:

• In the current version of the workflow plugin for the action in the workflow designer of formcycle, it is possible to specify the number of retries. If 3 is set here, then if an error occurs during printing, another 2 attempts will be made to print. Since the Chromium browser usually reinitialises its cache after the first failure, this can help to avoid the error.
• The print server has the command line flag "--isolatedBrowser" on startup. A new browser is then opened for each request to print a form (otherwise the same browser is used again and only a new tab is opened). A new user profile and cache directory is then also created each time and deleted again once printing is complete. As long as you don't have a high volume (constantly sending several messages per second), this shouldn't be a performance problem.
• The print server also has the command line flag "--userDataDir". This can be used to change the directory for the user profile, which also contains the cache directory. By default, the Windows temp directory is used, which may then be emptied by Windows or other programmes. It would then help to specify a different non-temp directory here.

These 3 options can also be used at the same time.

Example for starting the print server with both settings directly via the command line:

npm run server -- start --verbose=true --port=8090 --userDataDir=D:/formcycle/print-server/profile --isolatedBrowser

When using the installation script for the Windows service, the print service has to be stopped and uninstalled first, then the settings need to be added in the files "install-windows-service.js" and "uninstall-windows-service.js" at the top of "scriptOptions" and the service reinstalled.