Skip to content
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

[unreleased] AutoKuma db out of sync due to groups creation not prioritized #92

Open
landure opened this issue Nov 5, 2024 · 1 comment

Comments

@landure
Copy link

landure commented Nov 5, 2024

Hi,

I was incorrectly using master image. This issue occured:

with the introduction of AutoKuma database, an unwanted behavior appeared (with static monitors)

# group.toml
type = "group"
name = "My Group"
# alpaga.com.toml
type = "http"
name = "alpaga"
parent_name="group"
url = "https://www.alpaga.com/"
max_retries = 3
retry_interval = 60
notification_id_list = {"1"= true}

If alpaga.com is created before the group, Uptime Kuma responds with this error:

 WARN [autokuma::sync] Encountered error during sync: Server responded with an error: INSERT INTO monitor_tag (tag_id, monitor_id, value) VALUES (1, 92, 'group') - SQLITE_CONSTRAINT: FOREIGN KEY constraint failed

alpaga.com is created in Uptime Kuma, without parent group, but not stored in AutoKuma database.
AutoKuma will then create several alpaga.com probes, until the creation of the parent group.

This is also the case when the notification is missing.

This behavior was not an issue when AutoKuma based itself on labels to identifys its entries in Uptime Kuma.

@landure landure changed the title AutoKuma db out of sync due to groups creation not prioritized [unreleased] AutoKuma db out of sync due to groups creation not prioritized Nov 5, 2024
@BigBoot
Copy link
Owner

BigBoot commented Nov 7, 2024

Hmm I'd consider this a bug in uptime kuma tbh. The monitor should not be created if an error happens, I also can't just ignore the error on the autokuma side because I never get the id of the monitor in case of an error.

Btw this can only happen when manually referencing an id (e.g. in your notification_id_list), when using one of the _names the id is resolved locally, so this error is not actually originating from your monitor->group relation but something else. The error seems to indicate this is from a missing "Tag" not a missing parent monitor.

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

2 participants