Is the Custom UI bridge `requestJira`/`requestConfluence` Typescript interface correct?

I am developing a Custom UI and have been trying to call the requestJira function provided by @forge/bridge with an abort signal which keeps failing at runtime with the following error:

Failed to execute 'fetch' on 'Window': Failed to read the 'signal' property from 'RequestInit': Failed to convert value to 'AbortSignal'.

The code looks something like this:

import {requestJira} from '@forge/bridge';

const controller = new AbortController();
requestJira(`/rest/api/3/project/search`, {
              method: 'GET',
              headers: ...,
              body,
              signal: controller.signal,
            })

It seems when this request is passed through the bridge call, something goes wrong with the signal property. If I remove the signal property, it works just fine. From what I understand, the requestJira/requestConfluence API the user calls is just a simulated “fetch” call. Under the hood, the input is converted into a GraphQL request, which makes me wonder if the underlying API should attach the signal to the GraphQL request to allow us to abort it.

The signal property is probably unsupported, but it would be nice if this could be correctly represented in the types. Currently, the Typescript types tell that all standard fetch options are accepted/supported.

As a side note, passing a signal property to requestJira/requestConfluence from @forge/api works. From what I can tell, in this case, it is just calling the node-fetch API.

2 Likes

Same here. Can’t use signal property with requestJira… hence no way to actually abort requests that are in flight.

1 Like

Hi team, can someone look at this ? this has become a major prblem for our app now. requestJira is supposed to be compatible with fetch API, however abort signals are not supported.

1 Like

Bump :slight_smile: