Workunit and result states
The processing of workunits and results involves
several independent activities.
To keep track of these activities,
workunit and result database records have several "state" fields,
and their processing can be viewed as the combination
of several finite-state machines.
A workunit has the following state fields:
-
main_state:
Initially INIT.
If a canonical result is found (by validate)
it transitions to DONE.
If it's decided that no canonical result can be found
(by result_retry)
it transitions to ERROR.
-
file_delete_state:
Initially INIT.
When the main state transitions to either DONE or ERROR,
it transitions to READY,
indicating that input files can be deleted.
When file deletion is completed (by file_deleter)
it transitions to DONE.
-
assimilate_state:
Initially INIT.
When the main state transitions to either DONE or ERROR,
it transitions to READY,
indicating that the workunit can be assimilated.
When assimplateion is completed (by assimilator)
it transitions to DONE.
-
need_validate:
A boolean, true whenever
the workunit has a result whose validate state is NEED_CHECK.
The validate program sets it back to false.
A result has the following state fields:
-
server_state:
Initially UNSENT.
Becomes IN_PROGRESS when the result has been sent to a client.
Becomes DONE or ERROR if the client returns the result,
or TIMEOUT if result_retry gives up on the result.
-
client_state:
Records the client state (upload, process, or download)
where an error occurred.
Not relevant here.
-
file_delete_state:
Initially INIT.
When the parent workunit becomes ERROR, becomes READY,
indication that the output files can be deleted.
When the parent workunit becomes DONE, becomes READY
except for the canonical result, which remains INIT.
When the output files have been deleted (by file_deleter) becomes DONE.
-
validate_state:
Initially INITIAL.
When the result is returned, becomes NEED_CHECK.
When a canonical result has been found for the workunit,
becomes either VALID or INVALID.