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.

1 Like
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).