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; } } }

ScriptRunner Cloud and condition context

Jonathan Porta

Hi,

I've recently tried to implement an item work conversion in a JSM project with a ScriptRunner listener.

The listener reacts on Issue Updated. Then I have a condition to ensure that not all the updates trigger my conversion:

issue.status.name == "Awaiting dispatching"

&& issue.customfield_12689 != null

The custom field 12689 is called Conversion type, it is a single select which I use to determine which type of conversion I must be perform.

The conversion itself is quite simple, 3 actions (as the item is already in a common status between workflows):

Change work item type
Transition to the first status of the new workflow
Empty Conversion type

I have many issues with the Jira expression used for the condition, especially about changelog, which does not seems to be exactly aligned with the changelog object available in the groovy script, but now I have a even more strange thing:

At the whole beginning of my script I have this lines, which seem pretty standard:

final String issueKey = issue.key.toString()

final String encodedIssueKey = URLEncoder.encode(issueKey, 'UTF-8')

def workItem = WorkItems.getByKey(issueKey)


logger.info("Conversion listener V3 started for ${issueKey}")


def conversionType = workItem.getCustomFieldValue(Configuration.CONVERSION_TYPE_FIELD_NAME)

logger.info(

    "IssueType=${workItem.workType.id} " +

    "Status=${workItem.statusId} " +

    "ConversionType=${conversionType}"

)

with

@CompileStatic

final class Configuration {

    static final String CONVERSION_TYPE_FIELD_ID = 'customfield_12689'

    static final String CONVERSION_TYPE_FIELD_NAME = 'Conversion type'

    static final String CONVERSION_STATUS_NAME = "Awaiting dispatching"

    static final String CONVERSION_STATUS_ID = "10089"

My problem is that I sometimes receive errors from ScriptRunner showing that:

CorrelationId: Self=1-6ad70bee-5d46753e131cc04e2695fce2;Root=1-6ad70bee-0e870fea0ebb5c2b33aa8b42

Script identifier: 3b73cec6-4446-4c67-a3ef-6c1e22ee96df com.adaptavist.sr.cloud.events.WebhookExecution (avi:jira:updated:issue webhook fired for issue NWA-341230)  Took: 2965ms Logs:

2026-10-20 06:36:32.481 INFO - NWA conversion listener V3 started for NWA-341230

2026-10-20 06:36:33.008 INFO - GET /rest/api/2/issue/NWA-341230?expand=transitions%2Cnames%2Cschema asString Request Duration: 521ms

2026-10-20 06:36:33.486 INFO - IssueType=10041 Status=10091 ConversionType=null

2026-10-20 06:36:33.541 ERROR - No conversion rule is configured for Conversion type option ID 'null'. Configured IDs: [21115, 21116, 21117, 21119, 21153, 21186, 21219, 22984] at line 180

2026-10-20 06:36:33.542 ERROR - Class: com.adaptavist.sr.cloud.events.WebhookExecution, Config: null

How can the field Conversion type be null? How is that possible as the field is itself tested in the Jira expression?

Am I doing something wrong here?

Any help would be welcomed.

Accepted answers

All comments

Jonathan Porta

Oh and I forgot to add that I also opened a ticket with Adaptavist about changelog and that, but trying to get more information from the Community seems like a good idea.

Gor Greyan

Hi @Jonathan Porta,

I suspect this could be related to the difference between the issue data available in the listener condition and the issue data retrieved by WorkItems.getByKey().

Your Jira expression evaluates the issue context associated with the triggering event, while makes a WorkItems.getByKey() separate REST API request to retrieve the current issue state.

Since your conversion process also clears the Conversion type field, it's possible that:

The original update triggers the listener while Conversion type is populated.
Your script performs the conversion and clears the field.
Another Issue Updated event is processed using an earlier event context, but the REST API now returns the cleared field.

This could explain why the condition passes while getCustomFieldValue() returns null.

I would recommend adding a defensive check immediately after retrieving the field:

def conversionType = workItem.getCustomFieldValue(
Configuration.CONVERSION_TYPE_FIELD_NAME
)
if (!conversionType) {
logger.info("Conversion type is empty for ${issueKey}, skipping conversion.")
return
}

You could also check whether the current issue status still matches the expected conversion status before proceeding.

For additional troubleshooting, log the webhook's field value alongside the value returned by WorkItems.getByKey() to determine whether you're dealing with stale event data or subsequent updates.

If the listener continues to execute unexpectedly, consider checking whether the triggering changelog actually includes the Conversion type field.

Hope this helps!

Regards,
Gor

Jonathan Porta

Hi,

That's what I've done. I've added defensive code and idempotence checks on every action I perform, but it does not seem optimal.

I thought that the Jira expression was there to test if the ScriptRunner engine must be called or not, and in this case, it is absolutely not working.

I also had many issues with the changelog itself. Initially, what I wanted was to catch the transition to this status, so my condition was

issue.status.name == "Awaiting Dispatching"

&& issue.customfield_12689 != null

&& issue.changelogs[0].items.some(

    i => i.fieldId == "status"

      && i.toString == "Awaiting Dispatching"

)

But I add many conversions failing to start because even if the changelog containing the status update was not in the last record, so I had to remove that part.

For additional troubleshooting, log the webhook's field value alongside the value returned by WorkItems.getByKey() to determine whether you're dealing with stale event data or subsequent updates.

What do you mean by "webhook's field value" ?

Gor Greyan

Hey @Jonathan Porta,

By "webhook's field value," I meant the value available in the event payload passed to the listener, rather than the value retrieved through WorkItems.getByKey().

For example, you could log
logger.info("Event Conversion type: ${issue.customfield_12689}")
logger.info("Current Conversion type: ${workItem.getCustomFieldValue('Conversion type')}")

The idea is to compare the issue snapshot associated with the triggering event against the current issue state returned by the REST API.

If the event contains a value but the REST API returns null, that would support the possibility of a timing or event-processing issue.

Regarding your changelog condition, checking changelogs[0] assumes the relevant status change is always the first entry. That may not be reliable, depending on how the changelog data is structured.

However, I agree with your main point: the listener condition should ideally prevent unnecessary script executions.

I would suggest sharing the event payload and condition evaluation details with Adaptavist Support, as they can confirm exactly how ScriptRunner Cloud evaluates Jira expressions against incoming events.

The defensive checks are still useful, but they shouldn't be the only solution if the listener condition behaves unexpectedly.

Regards,
Gor

Jonathan Porta

Good idea, I will do that to be sure.

So basically, I should double check the context and then add test from the latest version before every action performed.

Jonathan Porta

I would suggest sharing the event payload and condition evaluation details with Adaptavist Support, as they can confirm exactly how ScriptRunner Cloud evaluates Jira expressions against incoming events.

About this specific point, I already shared the whole script with them, and many many logs. They said that they have no idea how the context of the Jira expression is provided and I should ask Atlassian. Funny, right?

Gor Greyan

Hey @Jonathan Porta,

Yes, exactly. I would recommend revalidating the current issue state before performing each critical action, especially since your listener modifies the same issue and may trigger additional update events.

Regarding Adaptavist's response, that's quite interesting! :) Since Jira expressions are evaluated by Jira, Atlassian may be able to clarify how the event context and changelog are populated.

However, I would still expect Adaptavist to help investigate how ScriptRunner handles the listener execution and its conditions.

Hopefully, you'll get some clarification from either side. Please share any findings, as this could be useful for others working with ScriptRunner Cloud listeners.

Welcome!

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

Quick Links

Find more posts tagged with

scriptrunner

jira

cloud

listener

jira-expressions