Why do some Webhook dumps NOT contain a UID 'TaskId' field?

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • DCE 2025.1.2
  • Deployed via .zip
  • Seeking explanation of missing ‘TaskId’ UID fields in JSON webhook output

As titled, there are some webhooks output following execution of sonar scans that possess a TaskId field, and some that don’t.

Expected, and most common output payload:

{
    "branch": {
        "type": "BRANCH",
        "isMain": false
        ...
    },
    "taskId": "561ad7ff-512a-464b-8tqc-69d2d524336a", 
    "status": "SUCCESS",
    "project": {
        "key": "my-project-key",
        ...
    },
   ...
}

but the occasional TaskId-less payload:

{
    "branch": {
        "type": "BRANCH",
        "isMain": false
        ...
    },
    "status": "SUCCESS",
    "project": {
        "key": "my-project-key",
        ...
    },
   ...
}

Why does this happen?

2

Checkout this thread.

3

Thanks Colin, but why can’t the TaskId be shared between the child/changed event source? Or, why can’t a fresh TaskId be generated and attached to the payload, if regeneration is equivalent to a new event/scan?

4

In January 2018, a decision was made to implement it this way.

In all seriousness, happy to hear about what you’re struggling with since the Task ID is missing from those responses. If there’s a concrete painpoint, would love to learn! If it’s just a case of “the others have it…”

5

The TaskId is a handy UID for logging webhooked event data and it’s a field that is ‘almost’ always there. It’s nice because it’s contextually unique and links the output event to source data. Without the TaskId, how should the exported event be linked back to the data in SonarQube? When the TaskId is missing, but we need a UID to hold the event against, we just generate our own. It’s unique, but the relationship between event and source isn’t there. Anyone seeking to follow the TaskId back to its specific event within the UI would not be able to.

8

If you scanned the same project twice in quick succession, and you were listening for webhooks for QualityGate events, you would get two events with different TaskIds right? If so, and you then wanted to trigger an API request for that event to get further data - you could take the projectKey and branch from the webhook payload and pass them into e.g. /export_findings&projectKey=dan&branch=main. However, if the second scan finishes before we fire off our first webhook’s corresponding export_findings request, we will receive the findings payload for the second scan - not the first. If you made use of TaskId here as a parameter for uniquely identifying a scan’s findings, you could be sure that the data generated from API requests referred to a specific scan.

9

@Colin, any update please? Is there a method to uniquely identify a webhook’s payload back to its quality gate event in the UI, when the payload doesn’t contain a TaskId?

10

Hey @dbeezt

I think the closest you could get right now is to try and correlate the analyzedAt field ( "analysedAt": "2025-08-15T15:28:38+0200",) to a specific analysis.

That said, I personally think it’s a good idea to always be including the analysis ID in the webhook – but it’s not up to me! I’ve passed the idea along to our PMs.

13

Hi @dbeezt,

It is possible for the QG to change when people mark issues as “Accepted” through the UI. When this happens, we send a webhook event, but this this change was not caused by an analysis, we don’t include the taskId.

We are considering adding an additional field to the webhook payload that indicates what kind of change triggered the QG change (analysis or manual issue resolution).

15

Hi @TomVanBraband, has there been any progress on such an additional field?

I’m not sure that a status field alone would achieve the solution I’d expect. It would need a TaskId to correlate it back to that original, specific QG Task, which has now been “Accepted”? However, I did appreciate your answer to the titled question, thanks.

@Colin , from your last message, it seems that we are aligned in our thinking. Was there any appetite for some form of task-specific analysis ID, or upgrading that TaskId to be more historically important?

18

Hi there @dbeezt , let me try to clarify the situation a little bit.

As discussed earlier, technically speaking, the `taskId` field contains the id of the task that processed the analysis responsible for changing the quality gate.

Quality gate changes can also result from UI changes (such as marking an issue as a false positive). In such cases, no analysis was involved, nor was there a task to process it; hence, the taskId field is missing.

I understand you built a workflow that reacts to quality gate change events (through webhooks) to download the findings associated with the branch in question. I understand that you are also trying to connect any quality gate change event to its source event, correct? What I don’t understand, though, is why?

Can you help me understand where the need to connect the quality gate event to its source event (specific analysis or specific UI change) comes from? And what is the ultimate workflow you are trying to build?

Understanding your workflows and needs in more depth will ensure we provide you with the best possible answer/solution.