Skip to end of banner
Go to start of banner

Request Traces

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

This document explains how to work with the new Request Traces feature introduced in Power Scripts for Jira Cloud version 3.2.0.

Feature Overview

The Request Traces feature provides visibility into Power Scripts' interactions with your Jira instance. When enabled, it logs all incoming and outgoing requests and allows you to monitor how your scripts communicate with Jira. By analyzing these I/O traces, you can better understand script behavior and optimize script performance.

Request Traces is an optional feature. It is disabled by default to maintain optimal performance. When enabled, Request Traces manages memory resources in the following ways:

  • Stores the 250 most recent trace operations.

  • Each trace captures the complete request chain, from the initial call to the final response.

  • Complex operations may generate extensive trace data, resulting in higher memory usage.

How to enable Request Traces

  1. In your Jira management console, open the Apps page.

  2. Navigate to the Power Scripts app and click Power Apps Config.

  3. Select Runtime > Traces.

The screenshot shows the Request Traces page where you enable the feature.
  1. To enable the feature, press the Enable traces toggle.

The screenshot shows the Request Traces feature is now enabled.

How to read traces

When initially enabled, the Request Traces page is empty. It gets populated when you execute scripts. Let’s get started by executing an example script.

  1. Open the test.sil file in SIL Manager and paste the following script:

string newKey = createIssue("TEST", "", "Story", "This issue was created by SIL"); //basic example of creating an issue
if(newKey != null) {
    //some additional changes to the issue after it is created.
    %newKey%.assignee = currentUser();
    %newKey%.labels += "sil_ticket";

}

What this script does is instruct Jira to first, create a new issue, and make two modifications to the issue:

  • Assign the issue to the current user.

  • Add the label sil_ticket to the issue.

  1. Run the script.

  2. Go to Power Apps Config > Runtime > Traces.
    The Traces page is now populated with a lot of traces. Let’s examine the trace generated by running this script.

    The screenshot shows the trace details generated by the example script.

number 1a.png

The ID and timestamp of the execution.

number2a.png

In the expanded primary thread (pool-9-thread-2), you can find the POST request for the initial issue creation.

number3a.png

The PUT request in the same thread is the issue update.

The execution of the script is now complete, but Power Scripts performs some automatic follow-up actions.

  • An issue refresh is triggered by the update, and this includes potential side effects from other add-ons.

  • The issue is passed for an indexing process to Thread 3.

number4a.png

The indexing process in Thread 3 is triggered by configured JQL keywords and standard properties.

  • The process performs checks for attachments, issue links, and comments with subsequent updates.

  • Next, the script executes a custom property calculation via another SIL file – slen.sil – and stores the JQL property results. Here’s what you need to know about the slen.sil execution to understand the traces in this example:

    • It didn’t generate an additional call to Jira (hence, there is no collapsible section in the trace).

    • It Runs in the context of TEST-10374.

    • Contains simple code: return length(summary);

While the trace explained above demonstrates Power-Scripts-initiated operations, you can also find Jira-initiated requests in additional traces logged with separate IDs.

The screenshot shows an example of two Jira-initiated requests.

These additional traces capture Jira's webhook activity: two webhooks were triggered in response to the issue creation and update operations, executing approximately one second apart. These webhook requests were completed rapidly since no additional processing was required in this case. You can identify these webhook-related operations in the trace by looking for HTTP-related thread names.

Working with traces

Since each trace captures the complete request chain, large operations may span multiple log files and consume a lot of memory. Two automatic safety controls prevent memory-related performance issues:

  • Only the 250 most recent traces are stored in memory.

  • The SIL Engine automatically disables trace collection upon restart.

For that reason, the search and filtering capabilities are limited to traces currently held in memory.

Some of the best practices for working with traces include the following:

  • For complex operations with extensive I/O activity, consider enabling traces only when needed for troubleshooting or optimization.

  • Trace data is automatically exported as JSON files to the logs directory. These logs can be analyzed locally or shared with support for detailed investigation.

  • No labels