v0.15.0 (Webhook Notifications!)

[alexjustesen]

What's Changed

• [Chore] Added one time operations package by @alexjustesen in [Chore] Added one time operations package #1100
• [Feature] Add webhook notifications by @alexjustesen in [Feature] Add webhook notifications #1103
• [Chore] Refactor notification channel tests by @alexjustesen in [Chore] Refactor notification channel tests #1104
• [Chore] Refactored get jitter data method by @alexjustesen in [Chore] Refactored get jitter data method #1105
• Release v0.15.0 by @alexjustesen in Release v0.15.0 #1106

Full Changelog: v0.14.7...v0.15.0

---

This discussion was created from the release v0.15.0 (Webhook Notifications!).

[masterwishx]

added https://discord.com/api/webhooks/XXXxXX/YYYY but not working , should i make some other steps ?

[alexjustesen]

Anything in the logs showing an error?

[masterwishx]

No errors, also no notification was sent, but in Gui it was sent...

[alexjustesen]

Did you try restarting the container and trying again?

[alexjustesen]

So looks like Discord requires some specific fields in the payload which is why it's rejecting the POST to the webhook. Current iterations of the webhook are meant for pretty basic payloads with just speedtest result info.

Going to say at this time Discord isn't supported but will make sure this gets added in the future.

https://discord.com/developers/docs/resources/webhook#execute-webhook

[masterwishx]

OK, waiting

[masterwishx]

[Starfiresg1]

Just noticed this - Webhook support is a great new feature.
Set it up with Gotify - test message worked out of the box 👍

[bonelifer]

@Starfiresg1 Could you give an example for Gotify.

[Starfiresg1]

Currently only the test message works - see #1213

[publi0]

Hi there! I'm seeking clarification on whether this behavior is correct.

When the webhook triggers and only one threshold has failed, the payload sent resembles this JSON structure:

{
  "result_id": 1633,
  "site_name": "Speedtest Tracker",
  "metrics": [
    {
      "name": "Download",
      "threshold": "450 Mbps",
      "value": "447.69 Mbps"
    }
  ]
}

In this case, the metrics field is an array. However, when there are multiple thresholds, the payload changes to this format:

{
  "result_id": 3931,
  "site_name": "Speedtest Tracker",
  "metrics": {
    "1": {
      "name": "Upload",
      "threshold": "400 Mbps",
      "value": "288.76 Mbps"
    },
    "2": {
      "name": "Ping",
      "threshold": "3 ms",
      "value": "4.41 ms"
    }
  }
}

Here, the metrics field is no longer an array; instead, it's represented as a map.

Context: I was implementing a listener for this webhook, and these JSON variations drew my attention.

[alexjustesen]

Great question, I'm open to feedback on what the format should be. I don't have any skin in the game for array vs. object map.

[publi0]

I find the map structure more advantageous, primarily because it simplifies the process of retrieving specific items. Using a descriptive key, such as the metric name, enhances clarity and ease of access:

{
  "result_id": 3931,
  "site_name": "Speedtest Tracker",
  "metrics": {
    "upload": {
      "threshold": "400 Mbps",
      "value": "288.76 Mbps"
    },
    "ping": {
      "threshold": "3 ms",
      "value": "4.41 ms"
    }
  }
}

This approach eliminates the need to iterate through each item to locate the desired one. However, transitioning to this structure would necessitate a change in the current API contract. Should this pose an issue, I think reverting to the array version would be better. The current map implementation, with numeric keys, adds no additional information; it merely replicates the array index.