Empty result set from JQL function invocation

Jira Development Jira Cloud
, ,
1

Hi folks, and @ljarzabek ,
I couldn’t find anywhere in the documentation, but how can we specify that no issue match the user query?
For instance, in the following query:
project = "projectKey" AND issue in myFunction() how do I specify that no results are matching ?

I’ve tried false and id in () with no success.

Also, it would be great if we could disable the cache on a function in the atlassian-connect descriptor.

Best regards, Corentin

2

Hi @Corentin, thank you for reaching out!

Unfortunately, there is currently a limitation in JQL, so it doesn’t support empty lists, and queries like issue in () will fail the validation. We have an internal discussion with the responsible team on supporting such queries, but I can’t promise anything at the moment.

As a workaround, your function could return any valid JQL that returns empty results, e.g., project is empty. We also do it in our example app here: Bitbucket
I know it is cumbersome, but currently, there is no other solution besides this workaround.

Regarding your second question, turning off the cache for JQL functions is not possible - precomputations are essential for the JQL function’s performance.
Could you provide more details about your use case? Why do you need to disable precomputations?

Best regards,
Łukasz

3 Likes
3

Thank you very much for the answer.

Converning the cache
Our problem is this:
We receive around a million jira issue updates per month, and I don’t know if we will hit 1000 jql function invocations anytime soon.

With the cache system the way it is,

  • We have to track the jql function invocations
  • We essentially have to run every search query for a given host when any issue is updated (ok, we can do some batching, maybe not every update needs to touch the search query at all, but it implies a lot of work, and potentially more bugs as we now have 2 sources of truth), and update Atlassian cache via rest (how do we even handle transactions for concurrent updates, network failures, rate limit ?) when we don’t even know if the search cache will be hit again.

Versus:

  • Have a 15min to 3 hours cache (or even better, let me specify a cache control max age, in the descriptor, or even in the request response).
  • Run the query when we receive it.

I might have misunderstood the architecture, please feel free to correct me.

I have another question regarding authentication:
I see in your example app that you used the @IgnoreJwt annotation (we use connect and java), and when I tried to use the @ContextJwt annotation, we would reject incoming requests. Is the best way to handle unauthorized access to verify that the @AuthenticationPrincipal user is null ?

Best regards, Corentin.

4

Hi @Corentin,

Cache
Thank you for the details and feedback about your use case. With the current design, we wanted to ensure that custom JQL functions won’t decrease the end-user experience. Invoking an app every time the function is processed may cause significant performance degradation of the JQL search. Moreover, the end-user may not necessarily know why the search is slower (e.g. when the JQL function is used within the predefined filter).

We are gathering all the feedback and will reevaluate our solution, but I can’t promise anything at the moment. Currently, the preferred approach is for apps to keep precomputations up to date. Every precomputation has a timestamp for the last time it was used. Your app could update only those frequently used precomputations (if you predict that there won’t be significant usage of your function). Bear in mind that the TTL of precomputation is currently one week. After that, the record will be removed, and Jira will invoke your app the next time the function is evaluated.

Authentication
I believe the @IgnoreJwt annotation in our example app is unnecessary; an app should work fine without it (I will remove it from the example code).

In general, the framework provided by Atlassian covers authentication and decoding of JWT tokens. You can find more information here, in readme: Bitbucket (“Responding to requests to an endpoint” section).

Also, here is our knowledge base regarding the JWT for Connect apps if you are interested in more details: https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/#understanding-jwt-for-connect-apps
I hope this information is helpful :slight_smile:

Best regards,
Łukasz

1 Like