-
Bug
-
Resolution: Unresolved
-
Low
-
Severity 3 - Minor
Issue Summary
When the payload sent to a JIra Automation Webhook trigger contains a field/object named "data", it's value can't be accessed using the smart value webhookData. The exact same JSON path can be parsed correctly if we replace "data" by anything else.
In the following payload, it is impossible to retreive the value at webhookData.data.essentials.alertRule.
{
"schemaId": "AWMonitorCommonAlertSchema",
"data": {
"essentials": {
"alertId": "/subscriptions/acfdb80a-aa1b-c12c-ac3d-eeeeee4e4e4e/providers/Microsoft.AlertsManagement/alerts/aaaa0a0a-bb1b-cc2c-dd3d-e128456e4e4e4e",
"alertRule": "TERPZ-R2-Gen2"
}
}
}
If you replace "data" by anything else, like "potato", the value will be parsed correctly.
This is reproducible on Data Center: (yes) / (no)
Steps to Reproduce
- Create a automation rule with an incoming webhook for the trigger.
- Add a log action and log "{{webhookData.data.essentials.alertRule}}"
- Set up Postman to post to the incoming webhooks url. Include the data set from above
- Send the POST message from postman to the webhook
- Check audit logs
Expected Results
Audit log would show "TERPZ-R2-Gen2" in the log entry
Actual Results
the log entry is blank under the log action
Workaround
Change the key name from "data" to something else and reference that key in the log action
[AUTO-1570] key named "data" in JSON body not parsed in incoming webhook.
| Description |
Original:
h3. Issue Summary
When the payload sent to a JIra Automation Webhook trigger contains a field/object named "data", it's value can't be accessed using the smart value {{webhookData}}. The exact same JSON path can be parsed correctly if we replace "data" by anothing else. In the following payload, it is impossible to retreive the value at {{webhookData.data.essentials.alertRule}}. {code} { "schemaId": "AWMonitorCommonAlertSchema", "data": { "essentials": { "alertId": "/subscriptions/acfdb80a-aa1b-c12c-ac3d-eeeeee4e4e4e/providers/Microsoft.AlertsManagement/alerts/aaaa0a0a-bb1b-cc2c-dd3d-e128456e4e4e4e", "alertRule": "TERPZ-R2-Gen2" } } } {code} If you replace "data" by anything else, like "potato", the value will be parsed correctly. This is reproducible on Data Center: (yes) / (no) h3. Steps to Reproduce # Create a automation rule with an incoming webhook for the trigger. # Add a log action and log "{{{{webhookData.data.essentials.alertRule}}}}" # Set up Postman to post to the incoming webhooks url. Include the data set from above # Send the POST message from postman to the webhook # Check audit logs h3. Expected Results Audit log would show "TERPZ-R2-Gen2" in the log entry h3. Actual Results the log entry is blank under the log action h3. Workaround Change the key name from "data" to something else and reference that key in the log action |
New:
h3. Issue Summary
When the payload sent to a JIra Automation Webhook trigger contains a field/object named "data", it's value can't be accessed using the smart value {{{}webhookData{}}}. The exact same JSON path can be parsed correctly if we replace "data" by anything else. In the following payload, it is impossible to retreive the value at {{{}webhookData.data.essentials.alertRule{}}}. {code:java} { "schemaId": "AWMonitorCommonAlertSchema", "data": { "essentials": { "alertId": "/subscriptions/acfdb80a-aa1b-c12c-ac3d-eeeeee4e4e4e/providers/Microsoft.AlertsManagement/alerts/aaaa0a0a-bb1b-cc2c-dd3d-e128456e4e4e4e", "alertRule": "TERPZ-R2-Gen2" } } } {code} If you replace "data" by anything else, like "potato", the value will be parsed correctly. This is reproducible on Data Center: (yes) / (no) h3. Steps to Reproduce # Create a automation rule with an incoming webhook for the trigger. # Add a log action and log "{{{{{}webhookData.data.essentials.alertRule{}}}}}" # Set up Postman to post to the incoming webhooks url. Include the data set from above # Send the POST message from postman to the webhook # Check audit logs h3. Expected Results Audit log would show "TERPZ-R2-Gen2" in the log entry h3. Actual Results the log entry is blank under the log action h3. Workaround Change the key name from "data" to something else and reference that key in the log action |
| Attachment | New: webhookData.data.png [ 469495 ] | |
| Attachment | New: webhookData.potato.png [ 469494 ] |
| Attachment | Original: Screenshot 2024-11-08 at 3.44.07 PM.png [ 469493 ] |
| Attachment | Original: Screenshot 2024-11-08 at 3.45.23 PM.png [ 469492 ] |
| Attachment | New: Screenshot 2024-11-08 at 3.44.07 PM.png [ 469493 ] | |
| Attachment | New: Screenshot 2024-11-08 at 3.45.23 PM.png [ 469492 ] |
| Development Effort | New: M [ 13032 ] | |
| Status | Original: Needs Triage [ 10030 ] | New: Gathering Impact [ 12072 ] |
| Labels | New: jsw-s13 |
The bug has been identified and is reproducible. In JiraIncomingWebhookTriggerExecutor.java, when processing incoming webhook events, the payload behaves differently based on the first nested key. If the first nested key is "data", it is ignored. However, if it is "potato" or values other than data it is processed correctly. This suggests a potential issue with deserialisation logic, possibly involving Jackson, due to specific handling or conflict with the key.
Example Log Outputs:
{"essentials":{"alertId":"/subscriptions/acfdb80a-aa1b-c12c-ac3d-eeeeee4e4e4e/providers/Microsoft.AlertsManagement/alerts/aaaa0a0a-bb1b-cc2c-dd3d-e128456e4e4e4e",
{"potato":{"essentials":{"alertId":"/subscriptions/acfdb80a-aa1b-c12c-ac3d-eeeeee4e4e4e/providers/Microsoft.AlertsManagement/alerts/aaaa0a0a-bb1b-cc2c-dd3d-e128456e4e4e4e",
To ensure you can access your data correctly, avoid using "data" as the first nested key in your payload structure. This can help prevent potential issues when retrieving values.
For example:
If your payload is structured as {value: { data: '123' }}, you can access the data using webhookData.value.data, and it will correctly return '123'.
However, if your payload is structured as {data:
{ author: '123' }}, you should access the value directly using webhookData.author, which will return '123'.