Workunit and result database records have several state fields, and their processing can be described in terms of state transitions.

Several workunits parameters are described here. Other state fields include "; list_start(); list_item( "canonical_resultid", "The ID of the canonical result for this workunit, or zero." ); list_item("transition_time", "The next time to check for state transitions for this WU.

" ); list_item("file_delete_state", "Indicates whether input files should be deleted. " ); list_item("assimilate_state", "Indicates whether the workunit should be assimilated. " ); list_item("need_validate", "Indicates that the workunit has a result that needs validation. " ); list_item("error_mask", "A bit mask for error conditions. " ); list_end(); echo " Workunit invariants:

Notes on file deletion:

  • Input files are eventually deleted, but only when all results have state=OVER (so that clients don't get download failures) and the WU has been assimilated (in case the project wants to examine input files in error case).
  • All output files (including errors) are retained until the WU has been assimilated. After that, the canonical result output files are retained until all other results are over and (if necessary) validated. Error output files can be deleted immediately. Success output files can be deleted after validation. "; list_start(); list_item("report_deadline", "Give up on result (and possibly delete input files) if don't get reply by this time. " ); list_item("server_state", "Values: UNSENT, IN_PROGRESS, OVER " ); list_item("outcome", "Values: SUCCESS, COULDNT_SEND, CLIENT_ERROR, NO_REPLY, DIDNT_NEED.
    Defined iff result.server_state=OVER " ); list_item("client_state", "Records the client state (upload, process, or download) where an error occurred. Defined if outcome is CLIENT_ERROR. " ); list_item("file_delete_state", "