Forge is not resending multiple "invoke" requests after the "Allow Access" screen (Custom UI)

Hi there,

It looks like we are encountering a bug in Forge related to the “Allow Access” screen. When a user wants to use your forge app for the first time and your app sends a request, a “Allow Access” button is displayed. The request of your app is stalled until the user gives the required permissions to your app.

That works pretty fine, but only if there’s one single “stalled request”. If there are multiple “stalled requests”, only the first one is actually finished, after the button is pressed. Here’s a demo of what that looks like (notice how “B” never finishes loading, because the graphql request isn’t resent):

The code needed to reproduce this is quite simple. First, you need a forge function that calls an endpoint which requires a scope:

import Resolver from '@forge/resolver';
const resolver = new Resolver();

// Make some request to trigger the "Allow Access" prompt
resolver.define('SOMETHING', async({context}) => {
	const spaceKey =;
	await api.asUser().requestConfluence('/wiki/rest/api/space/' + spaceKey);
	return 'DONE';

export const handler = resolver.getDefinitions();

For the frontend, I’m using Custom UI:

import React from 'react';
import ReactDOM from 'react-dom';
import '@atlaskit/css-reset';
import {invoke} from '@forge/bridge';

const fetchSomething = async(setValue) => {
	const value = await invoke('SOMETHING');

function BugDemo() {
	const [a, setA] = React.useState('Loading...');
	const [b, setB] = React.useState('Loading...');

	React.useEffect(() => {
		// Sending two requests at once, only first one will finish after "Allow Access"
	}, []);

	return (
			<li>A: {a}</li>
			<li>B: {b}</li>


In this example, we could of course very easily fix this by awaiting each fetchSomething call. But in our actual app we are sending several independent requests at once which we really cannot make wait for each other as that would massively slow down the loading time / performance of our app.

So my question is: Is there an easy way to prevent this from happening? Is there a way for us to send multiple requests at once without out the “Allow Access” process breaking our app?



Hi Sven!

Thanks for your question. Currently there isn’t an easy way to prevent this behaviour during the “Allow Access” flow, although subsequent renders of the app after refreshing the page should work as expected (i.e. once access has already been allowed).

As for the bug, we’ve now discovered the root cause and are working on a fix.

1 Like

Thanks for taking care @PeterYu ! We were aware that this is only happening the first time, but it still looks like to the user our app is broken, right? And (if they don’t refresh) for many this could already be a reason to write a bad review or to uninstall the app. So, we highly appreciate that you’re on it. :slight_smile:


Hi @sven.schatter, this issue should be resolved now. Please let us know if you continue to experience problems.

1 Like