nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Forge app function limit of 25 seconds blocker for response from remote agent using ROVO agent.

Vaibhav Govil

Hi Team, I have a remote AI agent deployed with REST endpoints exposed to send query and get response. I'm building a forge app to provide the support of our remote AI agent through the rovo:agent.

Everything is working fine but the function limit of 25 seconds of the forge app is killing that function and the reponse might take 7-10 minutes.

How can I extend the limit of 25 seconds or anyother workaround so that the user get the response in the same agent chat panel when the actual response from remote AI agent is fetched.

Accepted answers

All comments

Jairo Merea

Hola Vaibhav Govil,

The 25-second limit is strict in Forge and cannot be extended. For tasks taking several minutes, the official workaround is using the Async Events API.

Ideally, your function should return an immediate message in the chat (e.g., "Processing...") and push the AI query to a background async event. Once the AI finishes, you save the response (e.g., using Storage API) and use frontend polling to display the final result.

You can check how to implement it here:

Forge Async Events API: https://developer.atlassian.com/platform/forge/runtime-reference/async-events-api/?hl=en-US

Arkadiusz Wroblewski

Hi @Vaibhav Govil

Jairo's Async Events method is great for handling stuff in the background, but it won't just drop the final response right back into the Rovo chat.

For your use case, take a look at Rovo Agent Connector.

It can handle A2A streaming and has a 15-minute timeout, which is perfect for your 7–10-minute responses. Just so you know, your remote agent will need to set up an A2A 1.0 endpoint instead of the usual REST endpoint. Can you update your remote agent to support A2A?

Best,

Arek🤠🧙‍♂️

Vaibhav Govil

Thanks @Arkadiusz Wroblewski I have looked into the Agent Connector, but the documentation says that the remote agent must JSON RPC responses which is not supported by our remote AI agent.

Arkadiusz Wroblewski

You could use a small A2A adapter to connect Rovo with your REST API.

It translates JSON-RPC requests and handles long-running tasks in the background. Plus, since Jira supports GetTask polling, the final response can appear in the same Rovo chat once processing finishes.

Atlassian documents this here:
https://developer.atlassian.com/platform/forge/remote-agents-in-jira/

Vaibhav Govil

I'm implementing the rovo:agentconnector approach to integrate my remote AI agent in JIRA Cloud.

As the remote AI agent (exposed REST endpoints) is not supporting A2A protocol, I have created a A2A adapter in the forge container services which would communicate with my remote AI agent.

Now in the UI, my remote AI agent is getting displayed but which sending message in the chat panel, it's showing error: "Something went wrong. Please try again."

Can someone assist us in this or any references of how we can debug the issue as the logs are not getting printed in the developer console logs ?

Mihai_LeanZero

Hi @Vaibhav Govil,

Jira calls the agent endpoint itself over JSON-RPC 2.0, so the Forge function logs won't show it.

Check the container logs with forge logs --serviceKey <service> or -c <containerKey>.

Log each incoming request to stdout as a JSON line, with forge_invocation from the x-forge-invocation-log-attributes header (https://developer.atlassian.com/platform/forge/containers-reference/ref-logging/). Empty logs mean the request isn't reaching the container.

1. In that case, test with a plain HTTPS remote. Every agentConnector example uses one, and I can't find a container service shown behind it.
2. With streaming off Jira waits 55 s, so return a TASK_STATE_WORKING task at once with a new contextId and answer the GetTask polls.
3. On a non-production install, make the chatting user an app contributor.
4. Your adapter's FIT check may be rejecting Jira.

https://developer.atlassian.com/platform/forge/remote-agents-in-jira/

Could you share the manifest's endpoint block, the streaming flag and what the container logged?

Vaibhav Govil

Hi Team, we are implementing A2A agent which runs in a Forge Container. rovo:agentConnector only accepts a remote-backed endpoint (service: is rejected), so we route Rovo through our own web trigger, which forwards to the container. This works, but web trigger URLs differ per installation, in both host and path. Meanwhile remotes[].baseUrl is fixed in the manifest. For a Marketplace app, there’s no URL we can put there that works for every customer.

Questions:

- Is there a supported way for rovo:agentConnector to call a Forge Container service directly, such as a service-backed endpoint? Is that on the roadmap?
- If not, can a web trigger have a fixed, app-level URL, or can a remote resolve to the current installation’s web trigger (how the dynamic URL of the web trigger be pointed by the remote node in the manifest.yaml)?

Thanks !!

Mihai_LeanZero

Hi @Vaibhav Govil,

There's no documented way for agentConnector to call a container service, and I couldn't find a roadmap item for it. The reference only shows an endpoint backed by a remote baseUrl.
https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-agent-connector/

A fixed web trigger URL doesn't exist either. It's stable per app, site, module key and environment, so every installation gets its own. FRGE-1817 asks for one URL across installs. It's at Future consideration.
https://ecosystem.atlassian.net/browse/FRGE-1817

For a Marketplace app, I'd point baseUrl at one multi-tenant A2A gateway that validates the Forge Invocation Token and keys tenants on app.installationId. On avi:forge:installed:app and avi:forge:upgraded:app, a Forge function sends webTrigger.getUrl() to the gateway with invokeRemote, so the FIT proves which installation is registering. The gateway then forwards each call to that installation's trigger.
https://developer.atlassian.com/platform/forge/remote/essentials/

Web triggers are unauthenticated by default, so the container should check a secret from the gateway.

Does the work have to stay in the container?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

cloud

jira-cloud