Logic

Legend T = team J = task (job)

A note about errors: errors must be judiciously caught within "work" functions. If you don't catch these errors, they WILL blow up your application. This is as a result of problems with errors within nested functions in the callback loop.

Items that potentially create memory leak or add data to store that needs removal are numbered. + indicates creation of instance/item, ~ indicates read, and - indicates removal.

When a team is created:

1. Get team ID.
2. (+T01): Add team to team set (NOT CURRENTLY IMPLEMENTED).
3. (+T02): Add serialized team (NOT CURRENTLY IMPLEMENTED).
4. Begin heartbeat.

When a team is added to a factory:

1. Team is created.
2. (+T03): Team is added to Factory.teams
3. (+T04): Team "available" listener kicks in
4. Team is started.

When a team checks in:

How a team is monitored:

When a team is destroyed:

When a task is saved:
0. Task is assumed to have ID assigned (from create task or otherwise)

1. (~J04): If uid (unique id) present, ensure task with same uid doesn't exist.
2. (+J01): Add serialized task to tasks queue: [factory]:tasks:[taskId]
3. (+J02): Add task ID to waiting queue sorted set: :tasks:[type]:waiting
4. (+J03): Push task ID to type queue :tasks:[type]
5. (+J04): If uid is present, add to :tasks[type]:uids hash
   Result: [J01, J02, J03, (J04)]

When task is ready:
This occurs via BLPOP

1. (-J03): Pops task ID from type queue
2. (-J02): Pops task ID from waiting queue
3. Delegate task to team.
   Result: [J01, (J04)]

When team asked to delegate:

1. Create a worker.
2. (+J05) Add worker to worker queue.
3. (+J06) Listen to worker.
   Result: [J01, (J04), J05, J06]

When worker asked to work:

1. Task is retrieved.
2. (+J07) Task is activated.
3. (+J08) Set up local task listeners.
4. (+J09) Set up global task listeners
5. Start work.
   Result: [J01, (J04), J05, J06, J07, J08, J09]

When a task terminates
Termination may represent success, failure, delays or retries. This logic occurs in Worker.work:ensure

1. (-J06) Stop listening to worker. √
2. (-J05) Remove worker from worker queue. √
3. (-J08) Remove local task listeners. √

When a task succeeds

1. Announce "success"
2. (-J07) Remove from active.
3. Finalize
4. Terminate
   Result: [J01, J09]

When a task fails without more attempts:

1. Announce "failure"
2. (-J07) Remove from active.
3. Finalize
4. Terminate
   Result: [J01, J09]

When a task fails with more attempts

1. Announce "retry"
2. (-J07) Remove from active.
3. (-J09): Remove global listeners
4. (+J02): Add task ID to waiting queue sorted set: :tasks:[type]:waiting
5. (+J03): Push task ID to type queue :tasks:[type]
6. Terminate
   Result: [J01, J02, J03, (J04)]

When a task is finalized

1. Update metadata
2. (-J04) Remove from uid
3. Set expiration if necessary

When a task is removed
(-J09) Remove global task listeners.
(-J01) Remove task

How a task is monitored:

When a task emits an event:

When a task broadcasts a message:

When a listener is added to a task:

1. 'on' should take an additional argument that specifies whether to be local or global.
2. If listener is added within "work", events are added to localEvents only. This can be done in one of two ways: A. Create a preparation function that temporarily replaces task "on" with wrapper that includes boolean. Restore at end (fairly destructive) B. In addition to third argument, look at caller (arguments.callee.caller.toString())