Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Error: Monitor not found: � #82

Open
augustgerro opened this issue Sep 16, 2020 · 6 comments
Open

Error: Monitor not found: � #82

augustgerro opened this issue Sep 16, 2020 · 6 comments

Comments

@augustgerro
Copy link

augustgerro commented Sep 16, 2020 •
edited
Loading

I used to run the code and everything worked, now I'm running the plan and I get an unclear error:

Run

terraform plan

Output log

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

uptimerobot_monitor.stage_http["service_ABC"]: Refreshing state... [id=784909065]
uptimerobot_monitor.stage_http["service_ABC"]: Refreshing state... [id=784909066]
uptimerobot_monitor.stage_http["service_Z"]: Refreshing state... [id=784909059]
uptimerobot_monitor.st_http["http://xyz.com"]: Refreshing state... [id=784472891]
uptimerobot_monitor.stage_http["service_ABC"]: Refreshing state... [id=784909064]
uptimerobot_monitor.stage_http["rule"]: Refreshing state... [id=784909062]
uptimerobot_monitor.stage_http["service_ABC"]: Refreshing state... [id=784909060]
uptimerobot_monitor.st_http["http://xyz.com"]: Refreshing state... [id=784472893]
uptimerobot_monitor.stage_custom_port["https://TEST.com"]: Refreshing state... [id=784909058]
uptimerobot_monitor.st_keyword["http://xyz.com"]: Refreshing state... [id=784472892]
uptimerobot_monitor.st_keyword["http://xyz.com"]: Refreshing state... [id=784472890]
uptimerobot_monitor.st_keyword["http://xyz.com"]: Refreshing state... [id=784472888]
uptimerobot_monitor.st_http["http://xyz.com"]: Refreshing state... [id=784472889]
uptimerobot_monitor.stage_http["service_ABC"]: Refreshing state... [id=784909067]
data.uptimerobot_account.account: Refreshing state...
uptimerobot_alert_contact.slack_critical: Refreshing state... [id=2943593]
uptimerobot_alert_contact.slack_warnings: Refreshing state... [id=2943594]
data.uptimerobot_alert_contact.default_alert_contact: Refreshing state...
uptimerobot_monitor.dev_custom_port["https://TEST.com"]: Refreshing state... [id=784909072]
uptimerobot_monitor.dev_http["service_Z"]: Refreshing state... [id=784909073]
uptimerobot_monitor.dev_http["service_ABC"]: Refreshing state... [id=784909070]
uptimerobot_monitor.dev_http["service_ABC"]: Refreshing state... [id=784909063]
uptimerobot_monitor.dev_http["service_ABC"]: Refreshing state... [id=784909061]
uptimerobot_monitor.dev_http["rule"]: Refreshing state... [id=784909069]
uptimerobot_monitor.dev_http["service_ABC"]: Refreshing state... [id=784909068]
uptimerobot_monitor.dev_http["service_ABC"]: Refreshing state... [id=784909071]
uptimerobot_monitor.do_keyword["https://TEST.com"]: Refreshing state... [id=784619002]

Error: Monitor not found: �



Error: Monitor not found: �



Error: Monitor not found: �


Error: Got error from UptimeRobot: null



Error: Got error from UptimeRobot: null



Error: Got error from UptimeRobot: null



Error: Got error from UptimeRobot: null
@ray-jam
Copy link

ray-jam commented Sep 16, 2020 •
edited
Loading

I've seen this when monitors are deleted from outside of terraform (web portal). Provider code should handle it but looks like it needs a little bit of work but haven't had time to set up the source and debug.

Quick fix is to remove the resources in question from your statefile:
terraform state rm <resource-path>

The error message doesn't identify the resource unfortunately so you either know what they are or you'll have to figure it out some other way, terraform state list might help

@augustgerro
Copy link
Author

@ray-jam thank you!

But for me is not clear which resource is out of state. I guess, instead of � should be resource name

@louy
Copy link
Owner

louy commented Sep 17, 2020

Most terraform providers would fail in the same way. Agreed messaging could be improved (seems like that’s a bug itself), but getting an error when a resource is deleted outside of terraform is expected behaviour (I don’t think it’s even possible for a provider to delete its own state when an error like this happens) to protect users from irreversible consequences when network/server-side issues happen

@ray-jam
Copy link

ray-jam commented Sep 17, 2020

Couldn't find it to start with but check this part of the docs:
https://www.terraform.io/docs/plugins/provider.html#read

What it says is: If the resource is no longer present, calling SetId with an empty string will signal its removal.

I use AWS/Azure providers frequently and if someone has gone off script and deleted resources through the portal the subsequent terraform plan will just tell us "new resource" and recreate them. That is a lot easier on us as we don't have to jump in to the whole statefile management commands that are really there for exceptional circumstances.

The read function needs to error when it fails the call for authorisation or such but otherwise if you can identify it is just drift then SetId("") is recommended. Rough sample from the read function for a provider we were messing around with:

  info, err := auth.GetContactGroupInfo(groupID)
  if err != nil {
    return fmt.Errorf("Error from GetContactInfo: %s", err)
  }

  // If the resource does not exist, inform Terraform. We want to immediately
  // return here to prevent further processing.
  if info == nil || string(info.GroupID) != groupID {
    data.SetId("")
    return nil
  }

Guess it comes down to is it an error or just drift. If it is drift then ideally my plan will show me because I'll see the "new resources" being recreated when I review the output and they would be unexpected based on my changes at which point I can choose to cancel, update the tf code and plan again or just apply because I know they shouldn't have been deleted.

By the way thanks for the provider appreciate it being here :) and the effort behind it

@louy
Copy link
Owner

louy commented Sep 17, 2020

Ah makes sense. Wasn’t aware of this. Prob won’t have time to implement but if anyone else wants to send a PR I’ll happily merge

@kokarn
Copy link
Contributor

kokarn commented Oct 23, 2020

Encountered the same issue sadly, so anybody working on a PR would be much appreciated 👍

archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 14, 2021
@jelly
Terraform uptimerobot monitors
df07acc 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82
archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 14, 2021
@jelly
Terraform uptimerobot monitors
5690206 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82
archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 14, 2021
@jelly
Terraform uptimerobot monitors
7233187 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82

References: #209
archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 18, 2021
@jelly
Terraform uptimerobot monitors
792a5fa 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82

References: #209
archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 18, 2021
@jelly
Terraform uptimerobot monitors
ea8138d 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82

References: #209
archlinux-github pushed a commit to archlinux/infrastructure that referenced this issue May 18, 2021
@jelly
Terraform uptimerobot monitors
f741bc6 
Add our uptimerobot to terraform so it's managed in code and we can
easily extend it. This currently only adds our to be monitored sites and
leaves the status page as is now.

Deleting resources on uptimerobot will cause terraform unable to run
see: louy/terraform-provider-uptimerobot#82

References: #209
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@louy @kokarn @augustgerro @ray-jam