Skip to content

Instantly share code, notes, and snippets.

@maxx-coffee

maxx-coffee/tasker_states.md

Created September 18, 2019 13:03
Show Gist options
  • Save maxx-coffee/8918918f09faebe868740a0a97358193 to your computer and use it in GitHub Desktop.
Save maxx-coffee/8918918f09faebe868740a0a97358193 to your computer and use it in GitHub Desktop.
Download ZIP
tasker_states.md
Raw
tasker_states.md

Operations

State

Currently state is used for 2 purposes. The first purpose is to transition between states.

Example: Transition from select_url to audit_select_url

The second use of state is to signify if the operation is a system status. System statuses are used to perform an operation in our system.

Example: When a new operation is created it will have a state of "queued". This will allow our system to process the new operation.

Issues:

This couples too many things. We are depending on state in our system to also signify what the status of the operation is in our system. This leads to having operations in incorrect states.

Example: A user flags the operation and it moves it to a flagged state. We now have lost all visibility on where that operation is at.

Solution:

In the new implementation we are making states somewhat arbitrary and adding statuses. States will now only signify where the operation is on in relation to the workflow. The status will tell us the status of the operation.

Operation statuses:

  • Queued: the operation needs to be processed
  • Cancelled: the operation was cancelled by the requester
  • in_progress: the operation is being actively worked on
  • failed: the operation failed because a system error or was retried too many times.
  • flagged: the operation has been flagged by a user
  • complete: the operation has been fulfilled
  • waiting_for_resource: is the same as in_progress. The difference is the operation is waiting for user input from a task.

Tasks

Status

Currently task only work off statuses. This will indicate the status of a task.

Task statuses:

  • Completed: the user has completed a task
  • Flagged: the task has been flagged and cannot be worked on.
  • Cancelled: the operation was cancelled by the requester
  • Failed: the user failed the task (please see notes as this changed)
  • Ready the task has not been assigned to a user and is ready to be worked on.
  • In progress the task is currently being worked on by a user

Failed notes:

Currently a user has the ability to fail a task.

Example: On select url the user can select "none of the above" this will mark the task as failed.

This makes little sense as the task itself is "complete". We made the decision to move away from this. Now failed signifies if the auditor accepts or rejects the task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment