Extends the timeout of the task associated with the task ID provided. No-op if the task is not found, as this implies that the task has already been completed. This allows the client that is executing the task to continue working on it before the task is considered timed out.
ID of the task to extend the timeout for.
Timeout in seconds from the current time.
Grabs a number of unhandled tasks from the store. Unhandled tasks are tasks that are not currently in-flight/under processing (ie. tasks that have timed-out). NOTE: The implementation must make sure that once a task is grabbed by a client, tis timeout must be updated so that it is considered in-flight/under processing and cannot be grabbed by another client until it is timed-out.
Desired number of tasks to grab.
A list of tasks exclusive for the caller to handle; or empty array if there is no tasks, or if all tasks are already grabbed by others.
Reads the task associated with the task ID provided regardless of whether it is in-flight/under processing or not. This is mainly introduced for testing purposes: ie. to check the status of a task for easy test verification.
ID of the task to read.
Registers a new resumable task that is currently in-flight/under processing to the store.
If the task is timed out, a client will be able to grab it through the grab()
method and resume the task.
Task specific data. This is deliberately of type any
because this store should not have to be ware of its type.
Timeout in seconds from the current time.
A ManagedResumableTask
object that can be used to extend or delete the task.
Interface for interacting with the resumable task store.
Implementer's Note: The store implementation used in a horizontally scalable deployment, such as in a Kubernetes cluster, must account for concurrent access by multiple
ResumableTaskStore
instances. It would be undesirable to have many kubernetes pods all trying to handle the same resumable task. A minimal viable implementation can use a per tenant exclusive lock on the store whengrab()
and method is called. This would prevent issues that occur from concurrent modification to the same task to the store, but negatively impacts the throughput performance of the DWN. Requirements for a more performant implementation that allows distributed processing of resumable tasks across multiple clients:grab()
and/oropen()
implementation will need to copy the timed-out tasks from persistent store into the message queue/service for distributed processing by multiple clients when there is no resumable tasks to grab in the message queue. During the move, the persistent store should be locked to prevent multiple copies of the same tasks from being copied.delete()
can be called with task ID.