Error Handling

Group cohesion is very important to the design of the service. When handling multiple files (from a single archive or directory), the service will try to maintain transactional behavior by rolling back changes when encountering unexpected errors. This section describes the locations of these checkpoints.

The pipeline can be seen to have these stages:

• Qualification - When hopper activation criteria is tested against a changing file/directory
  • Any errors here are typically bugs and causes no ill effect, at worst a hard crash. Logs should indicate why
• Transform - When an executable is invoked against a file
  • If the executable returns non-zero status it is considered to have failed. When this happens the workspace is abandoned, the operator is expected to address the problem and submit the directory by renaming
• Import - When the transformed files, as a group, is imported into the central mono-collection
  • If a duplicate file is found in the workspace, the file is renamed to reflect the conflict. The workspace is abandoned and the operator is expected to resubmit the directory after addressing the conflict
  • The service shall make every effort to ensure the import is transactional (everything or nothing)
• Projection - When the files as a group is offered to stores
  • This is when files are projected into stores. The service treats each store as a transactional boundary.
  • The service will happily fail to project to all accepting stores and march on like nothing happened. At which point all files enters the lost and found as no store is holding it.