I investigated this a lot more today as it happened a lot more on the dependency updates section of the XWiki 18.0.0RC1 page, at some point I even thought it wasn't working at all. While I still think that storing those items in a cache is wrong, I don't think this is the root cause of these issues. I found a different cause that seems much more likely to me:
This empty part of the ID turns into an empty URL segment in the URL that is used to check the async job status/to load the async content.
Somewhere in the request chain to XWiki on xwiki.org we lose this empty segment in the URL. I have a minimal example with the async macro that works for me locally on Jetty and Tomcat (in Docker) but it doesn't work on xwiki.org. There, the empty segment is missing in the job ID. I suspect that the segment is lost in Apache as I still saw it in Apache's access logs.
So we get a wrong async ID in the AsyncRendererResourceReferenceHandler. Now you may wonder why it still works sometimes but not always. The reason for this is relatively simple:
While the job is still running when the async rendering status is requested by the browser, it needs to be retrieved from the job queue/currently running jobs - they are indexed by the job ID. This retrieval is (probably) always failing for the JIRA macro due to the missing empty segment. We're probably in this case where we need to retrieve the status from the job queue when the execution takes a bit longer like in the long list of updates for 18.0.0RC1.
When the job has been finished, it can be retrieved from the async rendering cache where the job status is stored after the job has been finished. It is indexed only by the clientId (a simple integer) which is transmitted as a separate URL parameter. Most likely, in contrast to what I initially assumed, this works in most or all cases for the JIRA macro when the computation finishes early enough.
The JIRA macro stops including null parts in the async job status ID
XWiki replaces null or empty parts by some other placeholder string
XWiki doesn't use the plain async ID as job ID but instead uses a cryptographic hash like SHA-512 of it to avoid problems with all kinds of characters in the URL path (or also too long paths, …)
The Apache configuration of xwiki.org is updated to pass empty path segments to XWiki and we document this as a requirement for XWiki
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.