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

Alert Contacts constantly changing, seeing the current contact as the first contact from getAlertContacts #6

Open
REBELinBLUE opened this issue Jul 17, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@REBELinBLUE
Copy link

REBELinBLUE commented Jul 17, 2024

I think there has been a change in the UptimeRobot API recently, whenever I plan, any uptimerobot_alert_contact shows it needs to be replaced, showing the existing id matching the correct contact but the friendly name and type showing the first contact returned by the getAlertContacts

I recreated this with a very basic setup

terraform {
  required_version = "1.8.5"

  required_providers {
    uptimerobot = {
      source  = "mindee/uptimerobot"
      version = "1.1.2"
    }
  }
}

provider "uptimerobot" {}

resource "uptimerobot_alert_contact" "webhook_website" {
  friendly_name = "Webhook - Website"
  type          = "webhook"
  value         = "https://example.com"
}

the plan was as expected

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # uptimerobot_alert_contact.webhook_website will be created
  + resource "uptimerobot_alert_contact" "webhook_website" {
      + friendly_name = "Webhook - Website"
      + id            = (known after apply)
      + status        = (known after apply)
      + type          = "webhook"
      + value         = "https://example.com"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

uptimerobot_alert_contact.webhook_website: Creating...
uptimerobot_alert_contact.webhook_website: Creation complete after 1s [id=6520503]

I then run plan again and get the following

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # uptimerobot_alert_contact.webhook_website must be replaced
-/+ resource "uptimerobot_alert_contact" "webhook_website" {
      ~ friendly_name = "lorenzo - e-mail" -> "Webhook - Website"
      ~ id            = "6520503" -> (known after apply)
      ~ status        = "active" -> (known after apply)
      ~ type          = "email" -> "webhook" # forces replacement
      ~ value         = "[email protected]" -> "https://example.com" # forces replacement
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: 
@REBELinBLUE
Copy link
Author

REBELinBLUE commented Jul 17, 2024

I think this might be an issue with UptimeRobot

https://github.com/mindee/terraform-provider-uptimerobot/blob/master/uptimerobot/api/alert_contact.go#L97

the GetAlertContact function calls the getAlertContacts API with alert_contacts set to the ID of the contact....
except it's returning other contacts, 4 rather than all 12 contacts in my case, and then of course the code expects there to be 1 contact in the response

https://github.com/mindee/terraform-provider-uptimerobot/blob/master/uptimerobot/api/alert_contact.go#L117

I made the same API call, setting limit to 1 and then it just returns the 3 additional contacts

I have reported this to UptimeRobot

@REBELinBLUE
Copy link
Author

From a defensive programming point of view though, it is probably worth GetAlertContact confirming it only has 1 result, and the ID matches the expected result, probably there is similar potential in GetMonitor

@paretl paretl added the bug Something isn't working label Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants