Cancelling Data Requests

When things inevitably go wrong or someone makes a mistake, the creator can cancel data they’ve requested. Data is cancelable up until a user provides the data, so even if a user is staked already, the dataset can still be cancelled. The reasoning is the same as in the case of changing a dataset time with a staked user. There are two operations for data cancellation: cancelling a single dataset and cancelling an entire request batch.

Additionally, a concept of staleness exists for datasets. If a user provides data, but for some reason no one else endorses any data for a very long time, then the dataset becomes stale and is eligible for cancellation.

1. Cancel One Or More Named Datasets (DataStoreCommon)

function cancel_datasets(
    address delegator_address,
    string[] calldata datasets_to_cancel) external;

A conceptually straightforward feature with a slight quirk. By specifying a list of datasets to cancel the creator can receive a refund of the coins they deposited for paying users. The quirk of this function is that there is an optimal ordering for the datasets in the case where the datasets have custom times. This is generally invisible to users, but anyone calling to cancel datasets directly (e.g., bypassing the front end using Remix, the command line, or another front end) should pass the datasets ordered from the latest to the earliest custom time.

2. Cancel Entire Batch (DataStoreCommon)

function cancel_request_batch(address delegator_address) external;

The other way to cancel datasets is by cancelling an entire batch. This will cancel any datasets that are cancellable when the transaction is being mined. This is a function that optimizes the cancellation by skipping expensive writes to storage that only update data that will never be accessed again, so it is preferable over calling to cancel individual datasets when appropriate to do so (such as the final remaining dataset(s) of a request batch).