Troubleshoot ScriptRunner Enhanced Search

Troubleshooting Tips

Occasionally you may see a red X warning next to your filter indicating there is an issue with it.

You can hover over the warning triangle to find out further information on the cause of the warning.

If hovering over the warning does not indicate an issue related to missing fields or projects, then this could indicate that the filter needs to be re-synchronized. You can re-synchronize the filter by running the search again and clicking the Sync Filter button, and check to see if the warning is removed. Refer to the Get Help section if you continue to see warnings with your filter.

(<number of issues in instance> * 0.00029) / 50

Enhanced Search Server to Cloud migration issues 

If you are encountering difficulties with your filters when migrating from ScriptRunner for Jira Server to Cloud, you can refer to our Troubleshoot ScriptRunner Migration section for help and guidance. In particular, we have outlined some common migration issues.

Understand performance on Cloud

It may sometimes appear that things seem a little slow on Cloud, here's why:

• We process updates in small batches to ensure the continued reliability of our system.

• When multiple users are engaged on the system at the same time, things might take a bit longer. System limits are in place to ensure fair resource sharing among all users.

• If you're running multiple searches, we handle them one at a time to make sure results are accurate.

Search performance

Below are some typical search performance expectations for Enhanced Search for Jira Cloud:

• Normally, searches return results within 2 minutes. However, if they take longer then they will time out - this helps keep everything running smoothly for everyone.

• Results may take longer to load during peak usage times.

Search tips

Here are some helpful tips you can use when creating searches:

• Break down large searches into smaller ones.

• Add project names to narrow down your search.

• Consider running complex searches during off-peak hours.

You can also refer to our Tips for Writing Queries.

For example, instead of searching across all projects:

issueFunction in linkedIssuesOfRecursive("status not in ('Done', 'Not Doing')")

Target specific projects:

issueFunction in linkedIssuesOfRecursive("project=PROJECTONE and status not in ('Done', 'Not Doing')")

Shared filter performance

Below are some typical shared filter performance expectations for Enhanced Search for Jira Cloud:

• Loading shared filters may take longer in Cloud environments

• The more shared filters you have, the longer they’ll initially take to load

• Performance may vary depending on how many people are using the system

Tips for better performance

Here are some helpful tips you can use when using shared filters:

• When possible, narrow down your searches by specific projects rather than instance-wide searches.

• Add date ranges if you don’t need all historical data.

• Share filter ownership across team members to distribute the processing load.

Filter sync performance 

When you save a JQL filter, our system syncs it in the background at regular intervals to give you the latest results. However, some factors can lead to occasional delays or incomplete updates.

What to know about filter syncing

• Sync Interval: The sync interval you set is the minimum time between checks to update your filters, i.e. how often we update your search results. However, actual updates may vary depending on filter complexity and whether filters are still being synced from a previous sync interval.

• A long-running filter is one that processes a large data set.

• Account Syncing Limits: Syncing happens independently for each user account. If a sync is already in progress for your account, new syncs will wait until the current one finishes. This ensures data consistency but can mean your filters may not update at the regularity of your sync interval.

Common reasons for sync delays

• Complex Filters: Filters with lots of data, complex queries, or custom functions (like linkedIssuesOf) take longer to sync. This can delay updates for other filters in the same account.

• Timeouts: Syncing has a 5-minute time limit. Filters that need more time may not fully update in each cycle. If a filter regularly hits this time limit, it will likely time out regularly during syncing.

When sync improvements aren't possible

There may be no effective way to improve sync frequency or reliability in certain situations. For example:

• Extremely Long-running Filters: If a filter takes longer than 5 minutes to run, it will not complete syncing within the time limit, and there’s no optimisation available that can change this.

• Heavy Data Filters: Filters that rely on extremely large datasets or involve intensive calculations (like multiple nested functions) may also reach technical limits. If the system cannot sync them within the available time, they will not update as frequently, no matter what changes are made.

In these cases, if syncing frequency or reliability is critical, consider simplifying the filter’s logic or using alternative filters with reduced complexity. If that’s not possible, you may need to manually refresh the results or adjust expectations for real-time updates.

Tips for faster filter syncing

• Simplify long-running filters
• If you have filters with complex queries, custom functions, or large data sets, try to simplify them where possible. Long-running filters can delay syncing for other filters within the same account. See our Tips for Writing JQL Queries.
• Delete unused filters:
• If you have filters that aren’t being used, consider deleting them. This frees up syncing resources, allowing active filters to sync more efficiently.
• Limit use of functions like linkedIssuesOf and parentsOf which add processing time. Use these sparingly for filters that need to sync frequently.
• Adjust sync intervals
• If you have long-running filters, consider adjusting your expectations for sync intervals across all filters. Longer intervals may be more realistic if some filters take considerable time to sync.

FAQs

Why isn’t my filter updating as frequently as I expected?

• The sync interval you set is how often we update your search results, but the actual syncing frequency can vary. This can happen if:

  • You have long-running filters (complex queries, large data volumes, or using functions like linkedIssuesOf or parentsOf) that take time to sync.

  • Another sync is already in progress for your account, so new syncs will wait until the current one is complete.

• To improve syncing, try simplifying any complex filters, removing unused filters, and setting realistic expectations for highly complex filters.

What can I do if my filters aren’t syncing reliably?

• Here are a few things you can try:

  • Simplify complex filters to reduce sync time.

  • Delete any unused filters that may be taking up sync resources.

  • Adjust sync intervals for complex or long-running filters to allow more time for each sync to complete.

• If you’ve tried these steps and still see issues, please reach out to support for further assistance.

Do unused filters affect syncing?

• Yes, unused filters can impact syncing. Even if a filter is short-running, it still takes up resources during each sync cycle. Deleting or archiving filters you don’t actively use can help free up resources and improve sync performance for the filters you rely on.

Can all filters be synced reliably, no matter how complex they are?

• Not always. Filters that take longer than 5 minutes to process may not sync, which can lead to incomplete updates or delays. If a filter is highly complex or processes a large amount of data, there may be no way to improve its sync reliability. For such filters, consider simplifying them or adjusting your expectations for real-time updates.

Common Errors

Issues with Renamed or Customized Epic Fields

If you've renamed or customized the Epic Link default field in your Jira instance, you may notice issues with epic-related queries in Enhanced Search, such as:

• Failures with getting automatic syncing and the most up-to-date results.

• Epic-related JQL functions (e.g., epicsOf, linkedIssuesOf) not returning expected results.

Cause:

Atlassian has deprecated the Epic Link field and now recommends using the Parent property to link to epics. Since the Epic Link field was customizable, any epic fields that you have renamed or customized are no longer supported in JQL queries.

Resolution:

To ensure your queries work smoothly, we recommend updating to Jira’s Parent field configuration to ensure compatibility.

Filter Search Results Not Automatically Updated 

This happens when the time it takes for your query to complete exceeds the sync interval (i.e., how often we update your search results) limit of five minutes. This may also happen if a filter is unused for 2+ months.

Resolution options:

• Manually refresh the filter: 
  Locate the saved filter and click refresh to get the most up-to-date results, as highlighted below.
  

• Simplify your query:
  Reduce the complexity or narrow down your search criteria. This helps the query to complete faster and fall within the sync interval rate. See our Tips for Writing Queries for more details.

Incorrect Board ID in Sprint Functions

• Sprint functions such as previousSprint() do not return expected results.

• The board ID believed to be correct does not align with current sprint data.

Cause:

This issue typically arises when teams switch to using a shared central board for sprint management but continue using an old board ID in their queries.

Resolution steps:

1. Verify the current board configuration:

   • Navigate to your Jira scrum board settings to confirm the board ID currently managing sprints. You must use the board ID of the board that the sprint was created from.

2. Update JQL functions:

   • Replace the board ID in your JQL functions with the ID of the centralized sprint board.

   • Example: Change all instances of previousSprint(boardId=234) to previousSprint(boardId=205).

3. Test the changes:

   • Run your queries to ensure they are now returning the correct issues.

Slow Performance with Negative Operators

• Queries using negative operators (e.g., not in, !=) take longer than expected to execute.

• Performance issues are more pronounced in larger Jira instances.

Cause:

Negative operators expand the search scope, requiring the system to process a larger dataset to exclude specified values.

Resolution steps:

1. Optimize JQL queries:

   • Combine negative operators with positive conditions to reduce the dataset being queried.

   • Example: Instead of status != "Closed", use status != "Closed" AND createdDate >= -30d.

2. Narrow the query scope:

   • Include additional limiting JQL clauses like project keys or specific fields.

   • Example: assignee in (currentUser()) AND status not in (Closed, Resolved).

3. Refine your approach:

   • Evaluate if a more straightforward query could achieve the desired results without using negative operators.

Unable to Save JQL Search

When saving a JQL query, and you receive an error message indicating that something went wrong and to try again later.

Cause:

• We have a 120-second timeout limit for searches manually triggered in the app, including the search that takes place when saving a filter. This may be the cause of the issue if you receive an error when the save request fails after stalling for some time.
• If you see an error stating that a 'Filter with the same name already exists' then it's possible that a Jira filter with the same name already exists. When you create a filter, both an ES copy and a Jira copy are generated, and they essentially both reference the same filter. However, the name used must be unique across both. If you name a filter in ES, it will carry the same name in Jira. Therefore, the error you're seeing is likely due to a naming conflict with an existing Jira filter.

Resolution steps:

Please try renaming your ES filter and saving it again.

No Results Returned for 'Epic' and 'Done' Query

• The issue type 'Epic' with a 'Done' status returns zero results.
• The intention is to list all epics where at least one child issue is marked as 'Done', or where all child issues are marked as 'Done'.

Resolution steps:

You can use the epicsOf() ScriptRunner Enhanced Search JQL function to write queries that will find epics with some or all of the child issues resolved.

For example:

• issueFunction in epicsOf('project= Demo and status = "Done"')
• issueFunction in epicsOf('project= Demo and status = "Done"') and not issueFunction in epicsOf('project = Demo and status != "Done"')

Restrictions on Searches for Users

Atlassian has announced that usernames or email addresses can no longer be used in filters, instead, the accountID should be used.. You can refer to their notification for more details.

For example, if you input a JQL query in the Enhanced Search UI using the /search/jql API endpoint (when searching with plain JQL), it will return results accordingly. However, the Atlassian search page does not use this API endpoint—it uses its own internal search mechanism.