Add "cancellation" support - AbortSignal

[lifaon74]

Almost all the methods are async. However, there is no way to cancel these async tasks.

What if we extend InteractionOptions with an AbortSignal ?

export interface InteractionOptions {
  signal?: AbortSignal,
  formIndex?: number;
  uriVariables?: object;
  data?: any;
}

For example, we could imagine:

// client
function run(thing: ConsomedThing) {
  const controller = new AbortController();
  
    // after 1000ms we abort the promise
    const timer = setTimeout(() => {
      controller.abort('timeout');
    }, 1000);

  // read the value
  return thing.readProperty('state', { signal })
    .then((output: InteractionOutput): Promise<DataSchemaValue> => {
      return output.value({ signal });
    })
    .finally(() => {
      clearTimeout(timer);
    });
}

Minimal scenario: the ConsumedThing aborts any async tasks related to this readProperty call (ex: aborts a fetch) and returns a rejected Promise (with an AbortError if we accept DOMErrors).

Extended scenario (optional): same as minimal scenario, but we may send an "abort" request too. In this case we may think about:

// server
function run(thing: ExposedThing) {
  thing.setPropertyReadHandler('state', ({ signal }) => {
    return fetch('https:///another-api.com', { signal });
  });
}

The client send an "abort" request for a specific property (ex: /property-name/abort/), or maybe if the server detects that the connection was terminated before he was able to send the property's value. In this case, the received signal in setPropertyReadHandler is aborted.

[zolkis]

Thanks for the note. We've been discussing cancellation earlier, also with AbortSignal/AbortController, as it's usable both in the browser and Node.js.

Cancellation is a difficult topic because all the differences in the network protocols underneath makes it difficult to map and guarantee cancellation. It's not just HTTP fetch under, but could be MQTT, OCF, HTTP.

Of course we could go with the client side cancellation, i.e. abort the request, reject the promises and the implementation should ignore any further protocol specifics on the client side.

We can discuss this in the next calls.
@ashimura @danielpeintner this is non-substantial, right?

[lifaon74]

Cancellation is a difficult topic because all the differences in the network protocols underneath makes it difficult to map and guarantee cancellation. It's not just HTTP fetch under, but could be MQTT, OCF, HTTP.

Yes exactly. To handle this case I noted two scenario:

• the minimal: where the "best effort" is done: at least reject if the Promise if not fulfilled, and if possible cancel any other related async tasks (like a fetch), or maybe a specific implementation of MQTT or whatever protocol, before it was sent (we may thing for example that data were buffered and were not sent yet)

• the extended: aborting the signal causes another "request" (depending on the protocol), to send an "abort" event or something similar, notifying the receiver (the server), that an abort was done. => this one is more complex, and it needs intensive thinking. Indeed, it's similar to simply calling an "abort" action with some specific params.

[relu91]

@ashimura @danielpeintner this is non-substantial, right?

I think it will cause some implementation effort for sure. In my understanding, we were settling for a consolidation phase without adding new features.

For future updates, I would definitely support the exploration of this feature. Mainly for two reasons:

1. It enables developers to improve UI/UX
2. It might also be interesting to see it connected somehow with cancelaction operations.

[relu91]

p.s. thank you @lifaon74 for reaching out and using your time to write a concrete proposal!