Task Queueing
alex muokkasi tätä sivua 6 vuotta sitten

Database format for tasks

Tasks is a MongoDB collection.

A task will include keys relevant to game logic:

  • Unique task ID (int) - UID per task
  • Action (str) - Task action type, equates to some async logic
  • Data (obj) - Arbitrary object can be stored to provide data

And also keys relevant to the task management system:

  • Timeout (int) - Timeout for the task to be completed in seconds
  • Claimants (arr[str]) - Array of bot IDs that claimed but rejected this task.
  • Current_Claimant (str) - Unique ID associated with the last bot to claim the task. null if rejected or unclaimed.
  • Attempts (int) - Number of attempts made at the task
  • Created_at (datetime str?) - Timestamp for when the task was created
  • Claimed_at - Timestamp for when the task was claimed null if rejected or unclaimed

Task actions

  • Create - Add a new task to the queue, specifying the promise, data and a timeout.
  • Claim - Lock a task to a bot, preventing it from being taken by another.
  • Release - Release the task back into the queue so it can be taken by another bot.
  • Resolve - Task was completed and can be removed from the queue.

Requirements for claiming a task

  • The current_claimant and claimed_at values must be empty.
  • The claimants array must not contain the bot's unique ID.
  • The attempts value must not exceed the global maximum limit.

Typical flow

  1. A game procedure creates a task, passing the relevant action type, any data required (for example, the player the task affects), and a timeout in which you would have expected the task to have been completed in.
  2. A bot has become free from it's previous task. It performs a claim action on the new task, which populates the claimant and claimed_at field. The task is now "locked" to the bot.
  3. The bot performs the actions detailed by the promise after verifying the claim. If the bot no longer has a lock onto the task (for example, due to a race condition) it will abort.
  4. After all actions have been completed successfully the bot resolves the task to remove it from the queue.

When things go wrong

  1. A game procedure creates a task, passing the relevant action type, any data required (for example, the player the task affects), and a timeout in which you would have expected the task to have been completed in.
  2. A bot has become free from it's previous task. It locates the new task, verifies it meets the criteria for a claim, and performs the claim action, which populates the claimant and claimed_at field. The task is now "locked" to the bot.
  3. The bot attempts to perform the actions detailed by the promise, but encounters an error.
  4. The bot releases the task (read: rejects), pushing its ID to the claimants array and incremementing the attempts value. Current_claimant and claimed_at will be reset.
  5. A new bot will attempt the task following the same procedure.
  6. If the number of attempts exceeds the system's maximum limit (defined in configuration), the task will be resolved without any actual action taken. Details of the problem will be sent to administrators, possibly through a private logging channel.

Timeouts

Where a task's timeout has been exceeded (calculated by claimed_at + timeout), the task should be released on behalf of the bot so it can be picked up by another. This will be done via the master program sending a termination singal to the bot, which will unlock the task and restart itself. This might require use of the network.