Azure / load-testing

Automate azure load test through github actions
MIT License
17 stars 17 forks source link

[BUG] Cannot read properties of undefined (reading 'dataPlaneURI') #69

Closed bm77525-kr closed 2 months ago

bm77525-kr commented 7 months ago

Describe the bug

When running the github action in 2 out of 3 of our environments, the action fails with the error: Cannot read properties of undefined (reading 'dataPlaneURI'). This is failing here: https://github.com/Azure/load-testing/blob/main/src/main.ts#L315. I added some additional logging to output the response in the working environment vs the environment that produces the error.

Working environment response

{
  "id": "REDACTED",
  "name": "REDACTED",
  "type": "microsoft.loadtestservice/loadtests",
  "location": "eastus2",
  "tags": {},
  "systemData": {
    "createdBy": "REDACTED",
    "createdByType": "Application",
    "createdAt": "2023-07-12T15:59:44.4797918Z",
    "lastModifiedBy": "REDACTED",
    "lastModifiedByType": "Application",
    "lastModifiedAt": "2023-07-12T15:59:44.4797918Z"
  },
  "identity": {
    "principalId": "REDACTED",
    "tenantId": "REDACTED",
    "type": "SystemAssigned"
  },
  "properties": {
    "description": "",
    "dataPlaneURI": "REDACTED.eastus2.cnt-prod.loadtesting.azure.com",
    "encryption": null,
    "provisioningState": "Succeeded"
  }
}

Response from environment that produces a failure

{
  "value": [
    {
      "id": "REDACTED",
      "name": "REDACTED",
      "type": "microsoft.loadtestservice/loadtests",
      "location": "eastus2",
      "tags": {},
      "systemData": {
        "createdBy": "REDACTED",
        "createdByType": "Application",
        "createdAt": "2023-07-14T18:21:01.0686353Z",
        "lastModifiedBy": "REDACTED",
        "lastModifiedByType": "Application",
        "lastModifiedAt": "2023-07-14T18:21:01.0686353Z"
      },
      "identity": {
        "principalId": "REDACTED",
        "tenantId": "REDACTED",
        "type": "SystemAssigned"
      },
      "properties": {
        "description": "",
        "dataPlaneURI": "REDACTED.eastus2.cnt-prod.loadtesting.azure.com",
        "encryption": null,
        "provisioningState": "Succeeded"
      }
    }
  ]
}

Expected behavior

The action should account for both response formats.

mohitpavan commented 7 months ago

@bm77525-kr, hi can you let us know more about the resource ? in my knowledge the get resource call should not return an array, it should return a single object ! can you try once more ? if the issue still persists, please let us know how old is the resource and the details about subscription.

mohitpavan commented 7 months ago

can you help us with the config you have used also ?

bm77525-kr commented 7 months ago

@bm77525-kr, hi can you let us know more about the resource ? in my knowledge the get resource call should not return an array, it should return a single object ! can you try once more ? if the issue still persists, please let us know how old is the resource and the details about subscription.

@mohitpavan I believe the date the resource was created is in the response payload: "createdAt": "2023-07-14T18:21:01.0686353Z",. The one that works was created only a couple days earlier. Out of 3 instances in 3 different resource groups, only 1 is returning the expected format and all others are returning an array. And yes, we've tried many times and finally forked this action so we could output the response that's causing the failure which you see above.

I'll be happy to provide subscription and resource specifics if there's a way to share those id's privately. I can say that the working instance is provisioned in an eastus2 instance provisioned in an eastus2 resource group. The other two are eastus2 instances provisioned in a centralus resource group. That would be the only differing thing from an infrastructure perspective.

bm77525-kr commented 7 months ago

After further investigation, I've narrowed this down to a missing environment variable for the resource name that's injected into the GH action config (loadtestResource). Because it was missing, it was an empty value being passed in which results in the generated ARM URL to be https://management.azure.com/subscriptions/REDACTED/resourcegroups/REDACTED/providers/Microsoft.LoadTestService/loadtests/?api-version=2022-12-01 (notice no resource name after loadtests/) so the API appears to return an array of all load test resources in the resource group. I'm closing this out due to it being a configuration issue, but it might also be nice to also guard against these empty values a little better or improve the debugging experience.

mohitpavan commented 6 months ago

@bm77525-kr created a workitem and will prioritise this one. thanks for the chance for us to look back on the validations, we will definetly take a look and work on the actionable errors.

mohitpavan commented 6 months ago

reopening this by seeing the issue is on our side, we will close this when we updte our actions.

mohitpavan commented 2 months ago

image we have added proper validation errors now.