az devops invoke does not resolve the route correctly in some cases - ends up hitting the wrong endpoint

[carlos-ricciardi]

This is autogenerated. Please review and update as needed.

Describe the bug

Command Name az devops invoke Extension Name: azure-devops. Version: 0.15.0.

Errors:

'type'
Traceback (most recent call last):
pip-install-6e754znd\knack\knack\cli.py, ln 206, in invoke
cli\core\commands\__init__.py, ln 603, in execute
cli\core\commands\__init__.py, ln 661, in _run_jobs_serially
cli\core\commands\__init__.py, ln 652, in _run_job
azext_devops\dev\common\exception_handler.py, ln 31, in azure_devops_exception_handler
    reraise(*sys.exc_info())
Temp\pip-install-6e754znd\six\six.py, ln 693, in reraise
cli\core\commands\__init__.py, ln 631, in _run_job
...
azure-devops\azext_devops\devops_sdk\client.py, ln 63, in _send
    query_parameters=query_parameters)
azure-devops\azext_devops\devops_sdk\client.py, ln 116, in _create_request_message
    url = self._client.format_url(route_template, **route_values)
pip-install-6e754znd\msrest\msrest\service_client.py, ln 151, in format_url
KeyError: 'type'

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• az devops invoke --area wit --resource workitems --route-parameters project=<project_name> id=<workitem_id>

replace <project_name> and <workitem_id> with valid values for a project in Azure DevOps and a workitem id

Expected Behavior

Return workitem details. Should work like the rest api: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/get%20work%20item?view=azure-devops-rest-5.1#workitemexpand

Environment Summary

Windows-10-10.0.18362-SP0
Python 3.6.6
Shell: powershell.exe

azure-cli 2.0.74 *

Extensions:
azure-devops 0.15.0

Additional Context

[carlos-ricciardi]

I think the problem is happening because the code isn't matching the correct location.route_template. When I call it with --debug I can see that is trying to match: azext_devops.devops_sdk.client : Route template: {project}/_apis/{area}/{resource}/${type}

Instead of: {project}/_apis/{area}/{resource}/{id}

The one that has id is for get work item: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/get%20work%20item?view=azure-devops-rest-5.1

The other that has type is for Get Work Item template: https://docs.microsoft.com/en-us/rest/api/azure/devops/wit/work%20items/get%20work%20item%20template?view=azure-devops-rest-5.1

Debug info attached. debug_azcli.txt

[ishitam8]

Thanks for logging the bug @carlos-ricciardi . We will look into the this.

Just curious, why are you using invoke command when there is a show by id command for work-item. Did you try? az boards work-item show --id <WORK-ITEM-ID> --org <ORG-URL>

[carlos-ricciardi]

Thank you for the reply!

I know about this command. The problem is that this command doesn't return the _links property and the rest api call does, If you could include this property in the return from az boards work-item show command would be even better :-)

Thanks a lot for the support, Carlos.

[atbagga]

There is an issue for adding support for asof field in workitem show command. I am modifying it to add support for asof, expand, and fields parameter in the command which should take care of the request here.

[ishitam8]

This is a separate issue where "_links" are not returned in the response, since it's populated in additional_properties of an object. It will still behave the same in spite of giving user an option to query all the links. Also, this is the behavior observed across all commands E.g az pipelines release show --id

So, its not linked to the other issue. i.e #535

[weshaggard]

I know this is a older issue but I'm hitting the same problem. The reason I was trying to use az devops invoke instead of az boards to update a workitem is because I need to set a multiline field which is pretty large and contains chars that need escaping if trying to pass them as a command line argument. For now I've worked around this issue by directly calling the rest api however that is causing me to need to pass a separate PAT to authenticate since I cannot share my "az devops login" credentials (well I couldn't figure out how to get an access token from my local login to pass to the rest api). It would be good if this can get accessed.

[asmundg]

It looks like the underlying issue is that there are two resources called 'workItems', and invoke unconditionally picks the second:

  {
    "area": "wit",
    "id": "72c7ddf8-2cdc-4f60-90cd-ab71c14a399b",
    "maxVersion": 6.1,
    "minVersion": 1.0,
    "releasedVersion": "6.0",
    "resourceName": "workItems",
    "resourceVersion": 3,
    "routeTemplate": "{project}/_apis/{area}/{resource}/{id}"
  },

  {
    "area": "wit",
    "id": "62d3d110-0047-428c-ad3c-4fe872c91c74",
    "maxVersion": 6.1,
    "minVersion": 1.0,
    "releasedVersion": "6.0",
    "resourceName": "workItems",
    "resourceVersion": 3,
    "routeTemplate": "{project}/_apis/{area}/{resource}/${type}"
  },

[BhargaviAnnadevara]

@ishitam8 This is still a bug and should be fixed. Have there been any updates since?

[PedroEss]

Facing the same issue trying to create Service Endpoint through Azure CLI by below command:

`

• $filepath = <JSON_configFilePath>

• $routeParamName = "project=$($projectName)"

• az devops invoke --organization $orgUrl --area serviceendpoint --resource endpoints --api-version '6.0' --in-file $filepath --http-method POST --encoding 'utf-8' --route-parameters $routeParamName -o json --verbose`

And this is response stack: INFO: route_parameter received is ['project=XYZ'] INFO: Creating connection with personal access token. ERROR: At least one project reference required to create an endpoint. INFO: Command ran in 3.143 seconds (init: 0.206, invoke: 2.937)

[AlexandreBouffard]

Facing this issue with conflicting route templates for same area-resource pair. The following route templates both have "area":"work" and "resourceName":"cardsettings":

• {project}/{team}/_apis/{area}/taskboard/{resource}
• {project}/{team}/_apis/{area}/boards/{board}/{resource}

Always hitting the first endpoint even if trying to hit the second one by specifying {board} route parameter.