Synthetic Location not applied in workflow for public location

[MaudVandevelde]

Describe the bug
I want to use a public location in a synthetic for Worklow and I have an error. For the public location it is not applied. it is written GEOLOCATION ...

It should be equal to MONTREAL (Amazon EC2)

To Reproduce
Steps to reproduce the behavior:

1. I define two synthetic location one private and one public:

data "dynatrace_synthetic_location" "location_interne_xxx" {
  type = "PRIVATE"
  name = "Windows On-Prem xxx"
}

data "dynatrace_synthetic_location" "location_externe_aws_montreal" {
  cloud_platform = "AMAZON_EC2"
  type           = "PUBLIC"
  name           = "Montreal"
}

2. I use those location in http monitor and browser monitor as code without any issue. I also use them in a worklow. I don't have any issue for the private location. But for the public location it doesn t work.
   In ressource dynatrace_automation_workflow:

    task {
      name        = "synthetic_xxxx"
      action      = "dynatrace.synthetic.workflow.action:synthetic-on-demand"
      description = "Trigger on-demand monitors in Workflows app"
      input = jsonencode({
     "location" : "${data.dynatrace_synthetic_location.location_externe_aws_montreal.id}",
...

3. When I reach the page in the workflow it seems that the location is not setted

If I set: "SYNTHETIC_LOCATION-000000000000003E" it works well.

Expected behavior
I am suppose to be able to use the ressource data.dynatrace_synthetic_location

Screenshots

[Reinhard-Pilz-Dynatrace]

Hello @MaudVandevelde

I must admit, I cannot fully explain at this point what has changed.

But here is what I know: The Terraform Provider is at the moment accessing the api/v1/synthetic/locations endpoint of the REST API - which shows exactly the behavior you've described. The ID of public synthetic locations is something like GEO-LOCATION....

Whether that was the case in the past I cannot tell. I need to reach out to R&D and find the right person.

What's puzzling about that: There exists now an endpoint api/v2/synthetic/locations in the REST API that produces the correct IDs. Not only that, when trying to use the old API via Swagger, it automatically reroutes to "v2".

So, instead of making a lot of guesses and trying to blame our devs responsible for the REST APIs, let's cut things short.
It looks like switching the Terraform Provider simply to the new endpoint solves the problem.

We are planning to push out a release anyways this week. A fix for that will be included.