Error handling¶

Dashboard error reporting¶

When a micro-service fails or encounters an error, the micro-service background turns from green to pink and a “failed” icon appears next to the transfer or SIP name:

The dashboard showing a transfer has failed at the Verify transfer checksums micro-service and has been moved to the failed directory

Note that the transfer has been moved to the failed directory and processing has been halted.

Clicking on the micro-service will expand to show the specific job that contains an error:

The Verify transfer checksums micro-service expanded to sholw the failed job

Click the tasks icon (the gear icon on the right-hand side) to open up an error report:

An error report showing that a virus has been found in a file

These reports are generally standard and predictable for certain types of errors and are useful for trouble-shooting. Note that the failed file(s) will always appear at the top of the report.

Failure reports in Administration tab¶

You can view failure reports in the Administration tab of the dashboard. See Dashboard administration tab- Failures for more information.

Email error report¶

If the user has an email address associated with their user account, the dashboard can email a failure report:

An emailed failure report showing an error at Verify bag micro-service

An e-mail is generated if the transfer or ingest cannot be completed, not if an error occurs which does not halt processing. Please note that the server must have mail delivery enabled in order to receive error emails without additional configuration.

Normalization errors¶

The dashboard will report normalization errors when:

• Normalization is attempted but fails
• No normalization is attempted and the file is not in a recognized preservation or access format

When normalization fails, the SIP continues processing until it reaches the normalization approval step. At this point, the user has two options:

Option 1

Click on the report icon next to the Actions drop-down menu to see a summary report of the normalization:

Normalization report showing failed normalization attempts

The report shows what has been normalized, what is already in an acceptable preservation and access format, and what has failed normalization or is not in a recognized preservation or access format. If normalization has failed, you can click on “yes” to see a task report of the error in a new tab:

Task output for failed normalization job

Option 2

Click Review in parentheses next to the micro-service to view the normalization results in a directory structure in a new browser tab:

Review normalization results in a new tab

The review allows the user to either open the objects in the browser when there is an appropriate plug-in or download the objects and open them using a local application.

The user may choose to continue processing the SIP despite any normalization errors.

The user may choose to redo normalization, as well. For instance, if the user chose to normalize based on FITS-JHOVE results and experienced failures, the user may wish to redo normalization and choose to normalize based on FITS-DROID results instead.

Redo normalization option in drop-down menu of Approve normalization job

Archivematica will send an email when normalization errors occur. Information given in the email report:

• UUID of the pipeline
• Name and UUID of the SIP
• File name and file UUID, and whether Preservation or Access normalization failed
• Exit code

Exit code 1 indicates that a normalization rule and command exists but failed to execute properly (due to a problem in the command, a problem with the file, etc). Exit code 2 indicates that a normalization rule/command does not exist for that format.

Emailed normalization error report

Dip upload error¶

Archivematica will allow the user to continue to attempt to upload the DIP if a mistake was made entering the permalink:

Warning that permalink was incorrect, allows user to retry upload DIP

Other common error behaviours¶

1. Verify metadata directory checksums: if the checksums in the metadata directory cannot be verified (i.e. if a file is missing or corrupted) the micro-service will fail and the transfer will be moved in the failed directory.
2. Scan for viruses: if a virus is found the micro-service will fail and the transfer will be moved in the failed directory.
3. Characterize and extract metadata: if FITS processing fails, the micro- service will fail and the transfer will continue processing. Similarly, if a tool within FITS fails, like JHOVE, you will see the pink error bar but be able to continue processing.
4. Remove thumbs.db file: if Archivematica is unable to remove a thumbs.db file, the micro-service will fail and the SIP will continue processing.
5. Normalize submission documentation to preservation format: if normalization fails, the micro-service will fail and the SIP will continue processing.

Rejecting a transfer or SIP¶

At any of the workflow approval points the user can choose to reject a transfer, SIP, AIP or DIP (depending on where the information object is in the workflow). This will move the transfer or SIP to the Rejected directory (accessible from the file browser) and will stop all processing on it. The transfer or SIP will still be listed in the dashboard, however. See Removing a transfer or SIP from the dashboard, below, to remove it from the dashboard.

Removing a transfer or SIP from the dashboard¶

To remove a transfer or SIP from the dashboard, click on the red “Remove” icon in the dashboard:

Click on the red Remove icon to remove a transfer or SIP from the dashboard, then click Confirm.

It is recommended that you clear your dashboard of transfers and SIPs periodically to improve browser performance.

Browser compatability¶

Archivematica has been tested most extensively with Firefox and Chrome. There are known issues with Internet Explorer 11 which result in an inability to start transfers in the dashboard (Issue 7246). Minimal, but successful, testing has been done with Microsoft Edge.

Back to the top