Skip to content

Notifications don't register, throw an error instead #110

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Mastermindzh opened this issue Dec 31, 2024 · 5 comments
Open

Notifications don't register, throw an error instead #110

Mastermindzh opened this issue Dec 31, 2024 · 5 comments

Comments

@Mastermindzh
Copy link

Hey,

I'm trying to add notifications but I keep running into errors.
I eventually tried applying the following labels (straight from the readme), but still receive the error.

      kuma.mynotificationprovider.notification.name: "This is a Matrix notification provider"
      kuma.mynotificationprovider.notification.active: "true"
      kuma.mynotificationprovider.notification.config: '{"type": "matrix", "accessToken": "XXXXXXXXXXXXXXXXXX", "homeserverUrl": "https://matrix.org", "internalRoomId": "!xxxxxxxxxxxxxxxxxx:matrix.org"}'

      kuma.mymonitor.http.name: "This is a Monitor with a notification provider"
      kuma.mymonitor.http.notification_names: '["mynotificationprovider"]'
      kuma.mymonitor.http.url: "https://example.com"

The error that gives:

autokuma-1  | WARN [kuma_client::util] Error while parsing notification: data did not match any variant of untagged enum EntityWrapper!
autokuma-1  | WARN [autokuma::sync] Encountered error during sync: Error while trying to parse labels: data did not match any variant of untagged enum EntityWrapper

I've also got a docker-compose where you can replicate it:

services:
  autokuma:
    image: ghcr.io/bigboot/autokuma:master
    restart: unless-stopped
    environment:
      AUTOKUMA__KUMA__URL: http://172.17.0.1:3001
      AUTOKUMA__KUMA__USERNAME: ${KUMA_USERNAME}
      AUTOKUMA__KUMA__PASSWORD: ${KUMA_PASSWORD}
      AUTOKUMA__TAG_NAME: AutoKuma
      AUTOKUMA__TAG_COLOR: "#42C0FB"
      AUTOKUMA__DEFAULT_SETTINGS: |-
        docker.docker_container: {{container_name}}
        http.max_redirects: 10
        *.max_retries: 3
      AUTOKUMA__DOCKER__LABEL_PREFIX: kuma
      AUTOKUMA__MIGRATE: true
    volumes:
      - ./autokuma/autokuma:/data
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - kuma

  kuma:
    image: louislam/uptime-kuma:1
    volumes:
      - ${APP_DATA}/uptimekuma:/app/data
      # - ${DOCKER_SOCKET}:/var/run/docker.sock
    ports:
      - 3001:3001
    restart: unless-stopped
    labels:
      kuma.mynotificationprovider.notification.name: "This is a Matrix notification provider"
      kuma.mynotificationprovider.notification.active: "true"
      kuma.mynotificationprovider.notification.config: '{"type": "matrix", "accessToken": "XXXXXXXXXXXXXXXXXX", "homeserverUrl": "https://matrix.org", "internalRoomId": "!xxxxxxxxxxxxxxxxxx:matrix.org"}'

      kuma.mymonitor.http.name: "This is a Monitor with a notification provider"
      kuma.mymonitor.http.notification_names: '["mynotificationprovider"]'
      kuma.mymonitor.http.url: "https://example.com"

Any help would be appreciated :)

@AurimasNav
Copy link

I'm also unable to create it using KumaEntity in kubernetes, getting:

INFO [autokuma::sync] Creating new Notification: testing
thread 'main' panicked at /usr/src/autokuma/kuma-client/src/client.rs:432:61:
called `Result::unwrap()` on an `Err` value: NotObject

@maddox
Copy link

maddox commented Jan 30, 2025

Is there a reason monitors added by AutoKuma don't respect the settings of existing Notifications in Uptime Kuma?

My Home Assistant notification is set to be Default Enabled, so all new monitors should just have it applied.

@BigBoot
Copy link
Owner

BigBoot commented Jan 30, 2025

The way AutoKuma works just isn't compatible with a 'default for new monitors' kind of setting. AutoKuma generates a desired state and then tries to mutate the existing uptime kuma state to fit the desired state. As a result there's no concept of a 'new' monitor in the desired state, it either exist or doesn't and there's no way to apply a setting only to "new" monitors.

@maddox
Copy link

maddox commented Jan 30, 2025

OK gotcha, I learned how to do this with AUTOKUMA__DEFAULT_SETTINGS

@Mastermindzh
Copy link
Author

@BigBoot,

Thanks for answering @maddox , glad his issue is cleared up.

But the original issue isn't about assigning a default notification. 😄
The original issues specifies that if we try to create a notification (even with the example labels from the readme) and try to assign it somewhere that AutoKuma throws an error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants