Improve Error Handling

[niemalsnever]

Hello,

this will be a somewhat general issue, but it's about one of our biggest gripes with the Alma Print Daemon. We are running a single centralized instance of the Alma Print Daemon handling all print jobs for our main library and the other branches. As can be expected for a software calling itself a "Daemon", runtime errors should not stop the general execution of the program and require manual intervention to clear. Errors should be logged, to a proper service log, and may even show up in the GUI, but must never stop the software from running.

In case of our Alma Print Daemon (shortened to APD from here on out), we regularly have raw JavaScript exceptions show up, which completely halt the execution of the APD and therefore the retrieval and execution of new print jobs. When this occurs, the error message must be manually acknowledged and the APD application restarted. This in turn basically means we need to have someone logged in to the server at all times, being ready to click "OK" and restart APD.

One such error message occurs, when the network printer which is supposed to print the currently worked on print job is unavailable. My guess as to why this occurs is that the printers are actually mapped to the account running the Daemon through Windows Group Policies, which are re-evaluated in regular intervals. When this happens to coincide with the job retrieval interval defined in the APD, the following exception may be thrown:

Uncaught Exception:
Error: webContents.print(): Invalid deviceName provided.
at WebContents._.print (electron/js2c/browser_init.js:173:7293)
at WebContents.<anonymous> (C:\Program Files\alma-print-daemon\resources\app.asar\main.js:240:30)
at WebContents.emit (events.js:228:7)   

To prevent this error, maybe the print job retrieval and printing routine can be adapted in such a way that the job is retrieved and then tried to print, if printing is successful, the next job is retrieved, if printing is not successful, the job is left in the printout queue (marked as not printed), the job ID is logged, and the print job can be retried in the next retrieval interval, in this case the next job is also fetched and printed.

The other frequently shown error message reads Cannot read property 'letter' of undefined. I do not have a current example, but I'm happy to provide one, as soon as the error shows up.

Please improve (or should I say implement) error handling and make the Alma Print Daemon actually robust enough have it run unattended, i.e. as a proper daemon. If you need any further information or context I am happy to provide it, as this issue has a real impact on our library's operations.

Regards

Sven Pagel

Edit: New Screenshot, updated error message, after updating to newest version 2.1.0 of the Alma Print Daemon, as the line number in the stacktrace has changed quite drastically.

[mgobat]

@niemalsnever, if you could grab an example of when the cannot read property 'letter' of undefined occurs, that might be helpful. It shouldn't be looking at the 'letter' property until it knows there is something to print. If the error provides a line number, that would be a bonus for tracking it down.

We will have a beta version later in 2023-April with better printing error handling, and a few minor enhancements..

[niemalsnever]

@mgobat It took a while but today the cannot read property 'letter' of undefined error "finally" showed up again, and I managed to grab a screenshot:

This is still version 2.1.0 as I haven't yet managed to update to 2.2.x-beta

The error reads:

Uncaught Exception:
TypeError: Cannot read property 'letter' of undefined
  at Function.<anonymous> (C:\Program Files\alma-print-daemon\resources\app.asar\main.js:246:113)

Hope that helps.

[mgobat]

Thank you, @niemalsnever. We will take a look. We've been looking into the "invalid deviceName" problem. The underlying framework we are using isn't trapping that particular error.; it appears to be a known defect in the framework. It also appears that a newer version of the framework may solve the problem. Unfortunately, a newer version of the framework breaks the ability to run the application as a Windows Service.

[mgobat]

@niemalsnever, please give the latest beta a try, if you like: https://github.com/ExLibrisGroup/alma-print-daemon/releases/tag/v2.2.0-beta-02

[niemalsnever]

@mgobat After upgrading to v2.2.0-beta-02 the daemon it crashed again on the second print job. Screenshot is attached:

[mgobat]

@niemalsnever, yes, sorry. I should have indicated that this beta doesn't address that particular issue. Please see earlier comment about the difficulty of trapping the "invalid deviceName" error. This beta will hopefully address the "cannot read property 'letter' of undefined error".

[niemalsnever]

@mgobat Ah, yes, okay, sorry! I will pay attention whether the cannot read property 'letter'... error will show up again. Like I said it didn't occur for the past several weeks but today (before upgrading to the new beta version it occured twice. Please regard my last comment as an update for which part of the code throws the invalid deviceName exception. It's very unfortunate that the new version of the library breaks the "running the APD as a service" capability, I hope that can be addressed in the future.

Best Regards

[mgobat]

No worries, @niemalsnever. My comment wasn't clear. Thanks for keeping a watch for the "cannot read property 'letter'" error. When errors occur, I'm hoping the new logging might help figure out the problem. We'll be looking to do some additional logging in another version.