{"id":1560,"date":"2025-10-17T10:00:16","date_gmt":"2025-10-17T07:00:16","guid":{"rendered":"https:\/\/www.drinkits.lv\/?p=1560"},"modified":"2025-10-17T16:55:43","modified_gmt":"2025-10-17T13:55:43","slug":"forges-5-minute-problem-how-i-built-a-blazing-fast-jira-cloud-attachment-scanner","status":"publish","type":"post","link":"https:\/\/www.drinkits.lv\/en\/2025\/10\/17\/forges-5-minute-problem-how-i-built-a-blazing-fast-jira-cloud-attachment-scanner\/","title":{"rendered":"Forge’s 5-Minute Problem: How I Built a Blazing Fast Jira Cloud Attachment Scanner"},"content":{"rendered":"

\"\"When I set out to build Attachment Architect, the main obstacle was clear: how do you scan a Jira instance with over 100,000 issues on a serverless platform designed with timeout constraints? The standard Atlassian Forge scheduledTrigger<\/code> runs only every five minutes. A rough calculation indicated it would take nearly two days<\/strong> to completely scan a large instance. This wasn’t a product; it was a science experiment. This is the story of how I abandoned the standard method, navigated Forge’s restrictions, and built a hybrid scanning engine that is more than 20 times faster<\/strong>, turning a two-day marathon into an 2-hour sprint.<\/p>\n

The Initial Failure: The Naive scheduledTrigger <\/em>Approach<\/h2>\n

All Forge developers start at this point. My initial prototype used a basic scheduled trigger that would run every 5 minutes, process a tiny batch of issues, and save its state. While it was dependable, it was unimaginably slow.<\/p>\n

<\/em><\/p>\n

\r\n+----------------------+\r\n| Trigger 1 (10:00 AM) | --- Processes Batch 1 ---> Sleeps for 5 mins\r\n+----------------------+\r\n\r\n+----------------------+\r\n| Trigger 2 (10:05 AM) | --- Processes Batch 2 ---> Sleeps for 5 mins\r\n+----------------------+\r\n\r\n+----------------------+\r\n| Trigger 3 (10:10 AM) | --- Processes Batch 3 ---> ...and so on.\r\n+----------------------+\r\n<\/code><\/pre>\n
The result: an issue processing rate of just ~40 issues\/minute. The complete scan of 100,000 issues was expected to take about 42 hours<\/strong>.<\/p>\n
I knew this was unacceptable. The user experience would be terrible. Nobody is going to wait two days for their initial results. I had to find a method to make the process continuous rather than intermittent.<\/p>\n
The Breakthrough: The Self-Invoking Webhook Pattern<\/h2>\n
Then, an amazing thing happened. I stopped depending on Forge to \u201cwake up\u201d my app every 5 minutes and instead, made my app \u201cwake itself up\u201d right after each batch.<\/p>\n
Here is the process:<\/h4>\n
    \n
  1. The user clicks “Start Scan.”<\/li>\n
  2. This action calls a Forge resolver that processes the first batch.<\/li>\n
  3. When Batch 1 is fully processed, instead of stopping, it makes a fetch<\/code> call to its own webTrigger<\/code> URL, in a way saying to itself: “I am finished, process the next batch right now<\/em>.”<\/li>\n
  4. The webTrigger<\/code> then takes care of Batch 2, and when it\u2019s done, it calls its own API once again.<\/li>\n
  5. This results in a fast, uninterrupted processing chain that is only limited by the Jira API, effectively ignoring the 5-minute scheduledTrigger<\/code> restriction.<\/li>\n<\/ol>\n
    The implementation of this technique resulted in a reduction in the scanning time for 100,000 issues from 42 hours to just over 2 hours<\/strong>.<\/p>\n
    <\/em><\/p>\n
    \r\n      [User Clicks 'Start Scan']\r\n               |\r\n               v\r\n+--------------------------------+\r\n| Resolver (Processes Batch 1)   | --[fetch]--> (Calls its own Web Trigger)\r\n+--------------------------------+       ^\r\n               |                         |\r\n        (Updates UI)                     |\r\n                                         |\r\n+--------------------------------+       |\r\n| Web Trigger (Processes Batch 2)| --[fetch]--> (Calls itself again)\r\n+--------------------------------+       ^\r\n               |                         |\r\n         (Saves state)                   |\r\n                                         |\r\n+--------------------------------+       |\r\n| Web Trigger (Processes Batch 3)| --[fetch]---- ... and so on\r\n+--------------------------------+\r\n<\/code><\/pre>\n
    Adding a Safety Net: The Hybrid Engine<\/h2>\n
    \"\"<\/a>But what if the user closes their browser? The “active” webhook chain might halt. At this point, I devised a hybrid system that would provide the best of both worlds.<\/p>\n
    The idea was to use the ultra-fast webhook method when the user was actively watching, but to have the reliable scheduledTrigger<\/code> act as a “watchdog” that would seamlessly take over if the active process stopped for any reason.<\/p>\n
    How it Works (Simplified):<\/h4>\n