Abort Jira Rest Api Requerst with AP.request

Hello. I am using Jira Rest API with AP to develop my connect app in React.
How can I abort the request?
Will this do the job?

    const response = await this._AP.request({
      url: "/rest/api/3/priority",

Hi @GHMahimaanvita ,

Unfortunately there isn’t a way to abort a request from AP.request. Do you mind elaborating on your use case? Would it be sufficient to just stop blocking on the response?


Okay cool
Hold on

Hello. I am developing a dashboard item (gadget) application in React. Based on the presence of existing config, I am swtiching between my app and the config screen. I am making some API calls in both the config form and my app on mount. Switching betweeen these screens is causing a React warning that there might be a memory leak in my api calls. I am trying to fix it using Abort controllers, but it does not seem to work:

const [isConfiguring, setIsConfiguring] = useState(false);
// ....
  useEffect(() => {
    const getConfig = async (): Promise<void> => {
      try {
        const config = await api.getDashboardGadgetConfig(
      } catch (error: unknown) {
      void getConfig();
  }, [api]);
{isConfiguring ? <GadgetConfigurationForm /> : <Gadget />}```

Here is a sample call:

async getPriorities(signal: AbortSignal): Promise<JiraIssuePriorityFull[]> {
    const response = await this._AP.request({
      url: "/rest/api/3/priority",
    return response.body && JSON.parse(response.body);

Thanks in advance!

Perhaps it is good to know that the Memory Leak warning has been removed from React 18, see also Remove the warning for setState on unmounted components by gaearon · Pull Request #22114 · facebook/react · GitHub

Oh, I did not know about this. This means I can safely ignore the warning, right? I am currently on an older version. I will update to React 18. Thank you

@remie On further thought, the update is about removing the warning, right? But there still are unnecessary api calls being made. Is there a solution for that?

Yes, it is indeed about removing the warning. But there is a reason for that: they found that in most cases, there was no need for cleanup.

The use-case for cleanup is when you setup a detached process in your useEffect handler which will continue running and use (memory) resources even when it is no longer required. A good example is web socket connections or interval timers. Even worse, given that your useEffect handler can be called multiple times, you would establish the same connection or set the same interval multiple times. This is why it is important to make sure that these types of persistent processes are cleaned up properly.

However, in the case of AP.request, once the request has been resolved, the process is terminated. It does not linger beyond that asynchronous request. As such, there is no memory leak.

Oh, I guess it is fine in that case then. Thanks for your help!