Unexpected response form an Automation action that gets data

Forge
, ,
1

I have an automation action that uses an endpoint for its execution.

The configuration and invocation are working as expected, but the response I see in the automation rule includes the whole endpoint information including headers and status code.

When I log the response form my action using a Log Action I see this

{success=true, payload={headers={date=[Fri, 03 Apr 2026 10:23:18 GMT], content-type=[application/json], transfer-encoding=[chunked], connection=[close], cache-control=[no-cache, no-store, max-age=0, must-revalidate], expires=[0], pragma=[no-cache], referrer-policy=[origin-when-cross-origin], x-content-type-options=[nosniff], x-xss-protection=[0], cf-cache-status=[DYNAMIC], nel=[{"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}], report-to=[{"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=KOqlJcoaqmJuW%2BzdNnoyBvrtibNugIcdhPLeXn4yYFq%2FEWm%2FRfD4c%2BmQdIii5lkZ8%2BXOtAIujAQMCiEGzvyfpFx70899IQKujls%2F%2F5Pt1ncsAuwdhYnR74HdslApnJc0xp2ZvCJjL1%2BRK1E%3D"}]}], content-encoding=[gzip], server=[cloudflare], cf-ray=[9e675b5b0cf71625-IAD], alt-svc=[h3=":443"; ma=86400]}, status=200, body=....}

Where I would only expect the contents of the body field.

Now to use the content of the action I need to select it using {{fetchedJenkinsJobList.payload.body}} instead of {{fetchedJenkinsJobList}} to access the response from the action.

This response also makes no sense when looking at the outputContext and outputs I need to configure for the action in the manifest.

Any specific reason the action using an endpoint is behaving this way that doesn’t match the documentation?

@JakubMierzewski I know you moved on to other parts of the code base, but as PM of the EAP do you know? Or know who to contact about this?

2

I got this response from Atlassian:

This seems to be an expected behaviour for FAA’s that use endpoints where in the full http response is enveloped by the platform and you see all the fields like status, headers, body etc. You can still access the desired data as mentioned on the post using {{fetchedJenkinsJobList.payload.body}} which should work correctly. This differs from how outputs and outputContext are documented for Forge actions — those are designed for actions that return values directly from a Forge function (via the resolver), and not from an endpoint’s HTTP response.

3

Good to know that this is expected behaviour from a technical standpoint.
But from a user point of view, this inconsistency can result in increased friction in adopting custom actions. Making it even harder since the difference in behaviour between endpoint and resolver based actions is not documented anywhere, and it is not visible to the user that there could be a different.

Any chance that inconsistency can be either

  • Resolved by making the endpoint based actions behave the same as resolver based actions

  • Document the difference in both the UI of Automation for Jira as well as in the docs.

It goes without saying that my preference would be the first option, but this will likely take longer.

4

I just came across this thread because I ran into similar issues. Unfortunately, I also spent quite some time before realizing that the docs only apply to Forge functions, and that the behavior for Forge Remote is different and undocumented.

I also can’t seem to get the error messages to work. The docs say to return a body like so:

{
      errors: [
        {
          message: `Payload provided with invalid issue key: ${issueKey}`,
        },
      ],
    }

But that does not seem to work when returned from a Remote. My understanding is that returning a 500 error from a Remote action invocation is treated like an exception from a Forge function, resulting in a generic error in the audit log (docs have this note: if your app throws an exception, the execution will be marked as failed too, but only a generic error message will be shown.).

So, I have tried returning a 200 or 400 status, but in those cases, the response is always considered a success, and the errors in the response body are basically ignored.

5

I am just working through the outputs and outputContext feature. The conclusion is that this feature simply does not work when an action is implemented via Remote.

@markrekveld do you know what the implications are of this not working for Remote actions?

I have a lot of questions about Remote actions only working halfway…

Does this only affect the UI, where users cannot select output values in the builder UI, and basically have to look up in partner docs which values the vendor returns?

I am worried that not having an output context would break things further down the line. What if we want to expose the action via an agent. If the action cannot provide an output context, how does the agent deterministically “know” what the action returns?

There is a rovo action documented, which I believe is actually the same module as the automation action module. There is no clear information about the differences. I believe they are sort of interchangeable. At least they go in the exact same place in the manifest.

6

Related Jira work item: https://jira.atlassian.com/browse/ECO-1577

7

Sorry @tbinna I missed your reply.

It does look like that in my experience.

I would like to think that Rovo, and other AI models, would be ‘smart’ enough to figure out the response they get form the action. However, I have not tested this yet.

The actual action module is the same and can be reused for automations and Rovo. To make it work for automations you will need to also have the automation:actionProvider module to expose the actions to the automation rule builder/executor.